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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the Stage 2 description for the Local Call Local Switch feature. Local Call Local Switch 
may be implemented in both BICC based CS core networks as defined in 3GPP TS 23.205 [2] and SIP-I based CS core 
networks as defined in 3GPP TS 23.231 [3], with a GSM/EDGE Radio Access Network supporting either TDM based 
or IP based A interface. 

This stage 2 shall cover the information flows between the GMSC server, MSC server and media gateways that are 
required to support Local Call Local Switching highlighting the specific requirements in addition to those defined for 
BICC based CS core networks 3GPP TS 23.205 [2] and SIP-I based CS core networks 3GPP TS 23.231 [3]. Note that 
nothing in the present document shall preclude an implementation of a combined MSC Server and MGW. The present 
document shall show the CS core network termination of the A interface, and the information flows between the ESS 
and the MSC server, in order to cover the information flow stimulus to the core network and describe the interaction 
with the supplementary and value added services and capabilities. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

BSS ID: A globally unique identifier of a Base Station Subsystem (ESS). 

call leg: The access link between the mobile station and the Core Network. A mobile to mobile call consists of two call 
legs and the link through the Core Network. 

call leg correlation: The process within the BSS to search for the other call-leg(s) of a (potential) Intra-BSS call by 
appropriate means. 

intra-BSS call: A mobile to mobile voice call involving two mobile stations connected to the same BSS. 

intra-BSS call detection: Determination that both call legs are within the same BSS. 
local call: An Intra-BSS call that can be locally switched by the BSS. 

locally switched call: A local call with a direct local path between the Call-legs, switched by the BSS. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

A Interface between the BSC and the MSC-S 

Abis Interface between the BSC and the BTS 

i intermediate node prefix. 

Mc Interface between the (G)MSC-S and the MGW. 

Nc The NNI call control interface between (G)MSC servers 

o originating side prefix, e.g. oUE, oBSS, oMSC, oMGW for nodes and e.g. oA-interface, 

oAssignment Request etc for interfaces, messages etc. 
t terminating side prefix , e.g. tUE, tBSS, tMSC, tMGW and e.g. tA-interface, tAssignment Request 

etc for interfaces, messages etc. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AoIP A over IP, using IP as the bearer of the user plane of A interface 

AoTDM A over TDM, using TDM as the bearer of the user plane of A interface 

APM Application Transport Mechanism 

COT Continuity message 

GCR Global Call Reference 

LCLS Local Call Local Switch 

OoBTC Out of Band Transcoder Control 



IVIain Concepts 



4.1 General 

Local Call Local Switch provides the capability for the user plane to be locally switched (e.g. voice data in user plane is 
not backhauled to the CS core network) for calls that are generated and terminated by users that are served by the same 
BSS. The result is saving on transmission resource of the Abis and/or A interface. 
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Local Call Local Switch shall only be considered for a CS voice call and is transparent to the end user. 

Figure 4.1.1 shows an example of Local Call Local Switching. It highlights only the main nodes and interfaces and 
differentiates between "originating" nodes and interfaces (oUE, oBTS, oMSC, oMGW, oAbis, oA) and "terminating" 
nodes and interfaces (tMSC, tMGW, tBTS, tUE, tAbis, tA). It also includes an Intermediate MSC server and MGW 
(iMSC, iMGW), which may be a (G)MSC server or other intermediate CN control node and its MGW. 



rwi 



Speech 
Signaling 

iMSC 




tBTS 



(with local switching 
Capability) 



"^scO 



Figure 4.1.1: Example of Local Call Local Switching 

The "active" User Plane path is shown with a thick, solid blue line for the case that Local Switching is provided 
between two BTS's, while the "inactive" User Plane path, i.e. the two Abis-links, the two A-links and the links within 
the Core Network are not carrying traffic and are therefore marked with thin, dotted blue lines. The Control Plane paths 
are shown in solid red lines. 

Local Call Local Switch is attempted to be instantiated during call establishment. During this phase, negotiation for 
support of LCLS is performed within the Core Network and requests to correlate and connect the call legs are made to 
the BSS when LCLS is successfully negotiated. Interaction with existing supplementary services and 
handover/relocation are supported. Depending on the scenario this may require a break of an existing locally switched 
call where the voice data on user plane shall be routed via the core network, or a (re)establishment of a locally switched 
call where the voice data on user plane shall be locally switched in the BSS. 

Local Call Local Switch may be supported on both TDM based A interface (AoTDM) and IP based A interface (AoIP). 

Local Call Local Switch may be implemented on both a BICC based CS core network and a SIP-I based CS core 
network and therefore the main concepts that are defined within 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] 
respectively, also apply to Local Call Local Switch. 

The MSC server is in charge of call control, supplementary services and gives permission (or denies) as to whether 
local switching may be applied. When the MSC server has granted the permission to apply LCLS, the BSC makes the 
final operation decision whether to establish LCLS (dependent on alignment of codecs, BTS's supporting local 
switching, resource available, status of its BTS's, the state of its radio legs). 

4.2 LCLS Negotiation 
4.2.1 General Concept 

LCLS negotiation is required within the Core Network in order to determine if all of the MSC servers and intermediate 
nodes, including GMSC servers, in the call control path allow the support of the LCLS functionality. LCLS negotiation 
may result in LCLS not being permitted for the following reasons: 

- An MSC server node or intermediate node, including GMSC server node, has not been upgraded to support the 
LCLS functionality. 

- It is prevented due to specific interactions e.g. Supplementary Services, operator determined restriction of LCLS, 
etc. 
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Additionally the LCLS negotiation may result in local call local switch being permitted but with certain configurations 
for user plane connectivity to the BSS depending on the network requirements, for example periodic signalling of pre- 
paid tones. 

The LCLS Negotiation Information Element is explicitly signalled on the Nc Interface. It is signalled during call 
establishment where the originating MSC server starts LCLS negotiation and may be signalled mid-call to attempt to 
establish LCLS or re-negotiate LCLS configurations, for example for mid-call tones or announcements where the node 
that requires change of a LCLS configuration initiates LCLS negotiation. 

Depending on the support of LCLS, the MSC servers and intermediate nodes, including GMSC server, may remove the 
LCLS Negotiation IE from further signalling on the Nc interface (e.g. if node does not support LCLS) or modify the 
contents of LCLS Negotiation IE (e.g. if LCLS is not allowed for the subscriber or if bicasting is required). 

The following properties are signalled in the LCLS Negotiation Information Element for "LCLS Allowed" to allow 
each node to indicate what level of user data connection it requires: 

- Need_Receive_Forward = No/Yes; this indicates if the node needs to receive UL data from the originating UE. 

- Need_Receive_Backward = No/Yes; this indicates if the node needs to receive UL data from the terminating UE. 

- Need_Send_Forward = No/Yes; this indicates if the node needs to insert user data toward the terminating UE. 

- Need_Send_Backward = No/Yes; this indicates if the node needs to insert user data toward the originating UE 

The default setting is "No" meaning that no Core Network user data requirement exists. If a node receives any of the 
parameters set to "Yes" it shall not change them; it may however change any parameter to "Yes". The parameters shall 
not be modified when sent in the response to an incoming LCLS -Negotiation IE request. 

If the call is locally switched with UL bicasting (Need_Receive_Forward = Yes or Need_Receive_Backward = Yes), 
the Core Network passes the user data through the Core Network as for a normally switched call, then any user data 
sent DL to the BSS is discarded by the BSS while locally configured as "connected both- way in the BSS" or "connected 
both- way in the BSS and bi-casted UL to the Core Network". 

If the Core Network also wishes to send data DL to UE (Need_Send is requested) and the distant call leg is not 
bicasting UL data, the local LCLS -Configuration is set to "Connected Bothway and Send Access DL" then the BSS 
may combine the local DL user data with the DL data from the Core Network. The local call leg may also be configured 
to "connected both- way in the BSS and bi-cast UL to the Core Network and send Access DL from the Core Network". 

If the Core Network also wishes to send data DL to UE (Need_Send is requested) and the distant call leg is bicasting 
UL data, the local LCLS -Configuration is set to "connected both- way in the BSS and send access DL from the Core 
Network, block local DL " to ensure that the bicasted UL data is not sent also via the local path to the UE i.e. the user 
would end up receiving the same data twice from the other UE. The local connection may also be configured to 
"connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network, 
block local DL". 

The following section describes in more detail the scenarios for the LCLS -Configuration settings when UL bicasting 
from the distant end coincides with DL send access at the local end. 

4.2.2 oMSC LCLS-Negotiation handling when receiving UL bicast and 
sending DL data 

If the oMSC server requires receiving UL data from the terminating UE and sending DL data to the originating UE then 
it shall perform one of the following: 

- send LCLS-Negotiation set to "LCLS -Not- Alio wed" or; 

- send LCLS-Negotiation set to "Need_Receive Backward = Yes, Need_Send_Backward = Yes" and set LCLS- 
Configuration IE to "connected both- way in the BSS and send access DL from the Core Network, block local 
DL" (as shown in Figure 4.2.2.1). If the BSS supports this configuration then LCLS will be allowed; otherwise 
LCLS will not be permitted. 
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Figure 4.2.2.1 : oMSC requesting UL data from tUE plus sending DL data to oUE 

If the oMSC server requires receiving UL data from the originating UE it shall either: 

- send LCLS-Negotiation with "Need_Receive Forward = Yes" (as shown in Figure 4.2.2.2) or; 

LCLS-Negotiation 
(Need Receive 




UE-0 UE-t 

Figure 4.2.2.2: oMSC requesting UL data from oUE indicated in LCLS-Negotiation 

send LCLS-Negotiation to the succeeding node with "Need_Receive_Forward = No" and if it does not receive 
"Need_Receive_Forward = Yes" in LCLS-Negotiation information element then it may configure its MGW to 
isolate the network side termination from the access side termination (as shown in Figure 4.2.2.3). 
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Figure 4.2.2.3: oMSC requesting UL data from oUE not indicated in LCLS-Negotiation 

If the oMSC server receives "Need_Receive_Forward = Yes" in LCLS-Negotiation information element then it 
shall configure its MGW to be both way through-connected (as shown in Figure 4.2.2.4). 



UL data 

requested from 

oUE by oMSC 

& (iMSC and/or 

■ tMSC) 



LCLS-Negotiation 
(Need Receive 




Result of LCLS-Negotiation 

Need_Receive_Forward = yes 

oMGW bothway through 

connected 



UE-o 



UE-t 



Figure 4.2.2.4: UL data requested from oUE by iMSC/tMSC, oMGW bothway through-connected 

If the oMSC server receives a LCLS-Negotiation information element set to "Need_Send_Backward = Yes" and 
"Need_Receive_Backward = Yes" then it shall perform one of the following: 

- send an LCLS-Negotiation forward set to "LCLS-Not- Allowed" or; 

- set LCLS -Configuration IE to "connected both- way in the BSS and send access DL from the Core Network, 
block local DL" (as shown in Figure 4.2.2.5). 

If the BSS supports this configuration then LCLS will be allowed; otherwise LCLS will not be permitted. 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 



18 



ETSI TS 123 284 VI 0.1.0 (2011-06) 



Ho apply a tone or ■ 
Knnouncement ■ 



MSC-S-0 



vLCLS-Negotiation^ 



-► 



XL 



MSC-S-I 



^LoLS-Negotiatior 
(Need Receive 
Backward, Need 
Send Backward) 



LCLS-Negotiation 
(Need Receive 
Backward, Need 
Send Backward) 



rULdata 
requested from 
tUE J 



MSC-S-t 



LCLS-Negotiation \ 
(Need Receive 
Backward, Need 
Send Backward) 



Option witli LCLS-Configuration 

IE: "connected both-way in the 

BSS and send access DL from 

the Core Network, block local 

DL" 




UE-0 



UE-t 



Figure 4.2.2.5: iMSC requesting UL data from tUE plus sending DL data to oUE 

4.2.3 tMSC LCLS-Negotiation handling when receiving UL bicast and 
sending DL data 

If the tMSC server receives LCLS-Negotiation with "Need_Send_Forward = Yes" and "Need_Receive_Forward = Yes" 
then it shall either: 

- return LCLS-Negotiation information element set to "LCLS-Not- Allowed" or; 

- return LCLS-Negotiation information element with value "Need_Send_Forward = Yes" and 
"Need_Receive_Forward = Yes" and set LCLS-Configuration IE to "Send Access DL, block local DL" (as 
shown in Figure 4.2.3.1). If the BSS supports this configuration then LCLS will be allowed; otherwise LCLS 
will not be permitted. 
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Figure 4.2.3.1 : iMSC requesting UL data from oUE and sending DL data to tUE 
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If the tMSC server requires sending DL data to the terminating UE and receives LCLS -Negotiation with 
"Need_Receive_Forward = Yes" but "Need_Send_Forward = No" it shall either: 

- return LCLS -Negotiation information element set to "LCLS-Not- Allowed" or; 

- return LCLS -Negotiation information element with value "Need_Send_Forward = Yes" and 
"Need_Receive_Forward = Yes" and configure its Access MGW to isolate the network side termination from the 
access side termination when LCLS is established (as shown in Figure 4.2.3.2), or; 
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Figure 4.2.3.2: iMSC requesting UL data from oUE and tMSC requesting DL data to tUE: option isolate 

access side termination from network side termination 

- return LCLS-Negotiation information element with value "Need_Send_Forward = Yes" and 

"Need_Receive_Forward = Yes" and set LCLS -Configuration IE to "Send Access DL, block local DL" (as 
shown in Figure 4.2.3.3). If the BSS supports this configuration then LCLS will be allowed; otherwise LCLS 
will not be permitted. 
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Figure 4.2.3.3: iMSC requesting UL data from oUE and tMSC requesting DL data to tUE: option send 

Access DL, block local DL 

If the tMSC server requires receiving UL data from the terminating UE and it receives LCLS-Negotiation with 
"Need_Receive_Backward = No" (as shown in Figure 4.2.3.4) then it shall either: 

- return LCLS-Negotiation with "Need_Receive Backward = Yes" or; 

- return LCLS-Negotiation with "Need_Receive Backward = No" and configure its MGW to isolate its access side 
termination from the network side termination. 
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4.3 LCLS Call Leg Correlation 

4.3.1 General 

LCLS call leg correlation is required in order to allow the BSS to identify that two call legs that are part of the same call 
are within the same BSS, and therefore can be correlated together to be a candidate for Local Call Local Switching. 

The originating MSC server shall generate a Global Call Reference (GCR) Information Element which is a globally 
unique call identifier for the duration of the call and needs to be sent to all nodes in the routing path. The Global Call 
Reference is further detailed within clause 1 1 . 

The originating MSC server and the terminating MSC server shall include the GCR Information Element in the 
ASSIGNMENT REQUEST and HANDOVER REQUEST messages. 

See Clause 6 for the detailed descriptions and related call flows for the call establishment procedures. 

The GCR may additionally be signalled within the core network for supplementary service interaction with LCLS and 
Inter-MSC Handover, this is further detailed in Clause 13 and Clause 8 respectively. 

On receipt of a GCR Information Element, if the BSS supports LCLS, the BSS shall store the GCR for each call leg 
until the call is released or that call leg is handed over to another BSS. 

NOTE: the inclusion of the LCLS-BSS-Status IE in the response indicates to the MSC server that the BSS 
supports LCLS. 

If the GCR and LCLS -Configuration Information Elements are included in the ASSIGNMENT REQUEST message, 
without the LCLS -Correlation-Not-Needed Information Element (see optional Intra-Network Detection, Sub-clause 
4.3.2 and optional Intra-BSS Call Detection, Sub-clause 4.3.3), the BSS shall perform call leg correlation and send the 
LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT COMPLETE message. 

If the GCR and LCLS -Configuration Information Elements are included in the HANDOVER REQUEST message, the 
BSS shall perform call leg correlation and send the LCLS-BSS-Status Information Element with the correct value 
within the HANDOVER COMPLETE messages. 

If the GCR, LCLS -Configuration and LCLS -Correlation-Not-Needed Information Elements are included (see optional 
Intra-Network Call Detection, Sub-clause 4.3.2 and optional Intra-BSS Call Detection, Sub-clause 4.3.3) in the 
ASSIGNMENT REQUEST message, the BSS shall either: 

- not perform any call leg correlation, but only store the GCR for the assigned call leg and send the LCLS-BSS- 
Status Information Element with the value "Call Not Possible to be Locally Switched" within the 
ASSIGNMENT COMPLETE; 

or 

- ignore the LCLS -Correlation-Not-Needed Information Element, store the GCR and perform call leg correlation, 
and send the LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT 
COMPLETE message. 

4.3.2 Optional Intra-Network Call Detection 

4.3.2.1 General 

As an option during call establishment, the tMSC server or the tBSS may utilise the Network ID within the Global Call 
Reference in order to determine whether the call is an intra-network call (e.g. compare the Network ID within the GCR 
with the Network ID of the tMSC server). 

4.3.2.2 Intra-Network Call Detection within the tMSC server 

The terminating MSC-Server may perform an intra-network call detection as follows: 

- if the Network ID in the GCR is the same as the Network ID of the terminating MSC-Server it means that the 
call is an intra-network call and the terminating MSC-Server shall proceed as for the case if no Intra-Network 
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Call Detection is performed i.e. including the GCR and LCLS -Configuration Information Elements, but not 
including the LCLS -Correlation-Not-Needed Information Element, within the ASSIGNMENT REQUEST 
message. 

if the Network ID in the GCR is different from the Network ID of the terminating MSC-Server it means that the 
call is not an intra-network call and the terminating MSC-Server shall include GCR, LCLS -Configuration, and 
LCLS-Correlation-Not-Needed Information Elements within the ASSIGNMENT REQUEST message. 

NOTE: Intra-Network call detection within the tMSC server can minimize the processing in some BSS 
implementations. 

4.3.2.3 Intra-Network Call Detection within the tBSS 

When receiving a GCR Information Element the tBSS may perform intra-network call detection as follows: 

if the Network ID in the GCR is the same as the Network ID of the terminating BSS it means that the call is an 
intra-network call and the terminating BSS shall perform call leg correlation. 

if the Network ID in the GCR is different from the Network ID of the terminating BSS it means that the call is 
not an intra-network call and the terminating BSS shall only store the GCR for the assigned call leg and does not 
need to perform call leg correlation. 

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS -BSS -Status Information Element within 
the Assignment Complete. 



4.3.3 Optional Intra-BSS Call Detection 



4.3.3.1 General 

As an option during call establishment, the tMSC server or tBSS may utilize the oBSS Node ID within the Call 
Reference ID of the GCR, in order to determine whether the call is an intra-BSS call (e.g. compare the oBSS Node ID 
with the tBSS Node ID) as described below. 

NOTE: After the oMSC server has generated the GCR IE, an Inter-BSS handover may occur at the originating 
side, therefore the encapsulated BSS ID is no longer the same as the BSS ID of the new Target BSS (see 
also sub-clause 8.4.1.1). Due to that, the result of the "BSS ID Pre-Check" procedure may be incorrect 
leading to "LCLS-Correlation-Not-Needed" indication being sent to the tBSS whilst the new target BSS 
could in fact be the same as the tBSS. If the tBSS does not perform the correlation of the GCR then the 
information in the Assignment Complete message may also be inaccurate (the LCLS -BSS -Status IE may 
indicate "call not possible to be locally switched" instead of "call not yet locally switched"). If the tMSC 
server indicates "LCLS-Correlation-Not-Needed" and the Inter-BSS handover has occurred at the oUE 
into the same BSS as the tUE but after signalHng the GCR IE and the tBSS does perform full GCR 
correlation then the LCLS-BSS-Status will indicate accurately that the call can be locally switched. 

4.3.3.2 Intra-BSS Call Detection within the tMSC server 

The terminating MSC-Server performs intra-BSS call detection as follows: 

- if the oBSS Node ID in the GCR is the same as the terminating BSS Node ID, the terminating MSC-Server shall 
proceed as for the case when no Intra-BSS Call Detection is performed i.e. including the GCR and LCLS- 
Configuration Information Elements, but not including the LCLS-Correlation-Not-Needed Information Element, 
in the ASSIGNMENT REQUEST message (if LCLS is otherwise allowed from CN point of view). 

- if the oBSS Node ID in the GCR is different from the terminating BSS Node ID, the terminating MSC-Server 
shall include the GCR, LCLS -Configuration, and LCLS-Correlation-Not-Needed Information Elements within 
the ASSIGNMENT REQUEST message. 

NOTE: Intra-BSS call detection within the tMSC server can minimize the processing in some BSS 
implementations. 
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4.3.3.3 Intra-BSS Call Detection within the tBSS 

When receiving a GCR Information Element the tBSS may perform intra-BSS call detection as follows: 

- if the oBSS Node ID in the GCR is the same as the BSS Node ID of the terminating BSS the terminating BSS 
shall perform call leg correlation. 

- if the oBSS Node ID in the GCR is different from the BSS Node ID of the terminating BSS the terminating BSS 
shall only store the GCR for the assigned call leg and does not perform call leg correlation. 

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS -BSS -Status Information Element within 
the ASSIGNMENT COMPLETE message. 

4.4 LCLS Connection Control 

LCLS connection control enables the Core Network to indicate to the BSS when the call is requested to be locally 
switched within the BSS or not. LCLS connection control is explicitly signalled on the A interface during Call 
Establishment, Handover and LCLS Break/(Re)Establishment using the LCLS_CONNECT_CONTROL message. 

Within the LCLS_CONNECT_CONTROL message, the LCLS -Connection-Status-Control Information Element shall 
indicate whether the BSS is requested to: 

- establish local switching (connect) 

- do not establish local switching (this value is used for example in call hold to explicitly prevent LCLS 
connection) 

- bi-cast at handover (this is a temporary status for the other call leg which is not being handed over. After 
handover has been completed and LCLS is broken, the BSS shall adopt the previous LCLS -Connection-Status- 
Control value i.e. "connect" unless explicitly changed by the MSC Server. This means that any subsequent 
handover of the previous call leg back into the same BSS will enable LCLS without any change of LCLS - 
Connection-Status to this call leg) 

- release LCLS for the locally switched call (Release LCLS) 

LCLS through-connection is established when the BSS receives, on both call legs, the LCLS -Connection-Status-Control 
IE to allow and request LCLS to be established. 

The detailed call flows and procedures for signalling of the LCLS-Connection-Status-Control IE during Call 
Establishment, LCLS Break/(Re)Establishment, and Handover are defined in clauses 6, 7, and 8 respectively. 

The LCLS_CONNECT_CONTROL message and the usage of the LCLS-Connection-Status-Control IE are further 
detailed in sub-clause 16.3. 

4.5 LCLS Status Reporting 

4.5.1 LCLS BSS Status between BSS and Core Network 

LCLS BSS status is required between the BSS and the Core Network in order to keep the originating MSC server and 
the terminating MSC server updated of the LCLS status in the respective BSS. 

The LCLS -BSS -Status Information Element is used to indicate whether: 

- the call is locally switched 

- the call is local but not yet locally switched (this indicates that the call has been correlated but not locally 
switched) 

- the call is not possible to be locally switched (this indicates that the call has been determined not to be a local 
call) 

- the call is no longer locally switched 
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- the requested LCLS -Configuration is not supported 

The inclusion of the LCLS-BSS-Status Information Element in responses to the MSC server indicates support of LCLS 
feature by the BSS. The usage of the LCLS-BSS-Status Information Element is further detailed in sub-clause 16.3. 

The LCLS-BSS-Status IE is explicitly signalled on the A interface during Call Establishment, LCLS 
Break/(Re)Establish LCLS, and Handover procedures. See clauses 6, 7 and 8 respectively. 

The LCLS-BSS-Status IE is also signalled expHcitly in the LCLS_NOTIFICATION message on the A interface, 
triggered by the BSS to notify the core network of any LCLS status changes in the BSS, e.g. BSS Initiated LCLS Break. 
The LCLS_NOTIFICATION message is further detailed in sub-clause 16.3. 

4.5.2 LCLS Status within the Core Network 

LCLS status is required within the Core network in order to update all of the (G)MSC server and intermediate nodes in 
the call control path of the LCLS status of the call. 

LCLS -Status Information Element is explicitly signalled on the Nc interface during Call Establishment, LCLS 
Break/(Re)Establish, and Handover procedures when the LCLS status changes from before and after handover. See 
clauses 6, 7, and 8 respectively. The LCLS-Status is either indicated as changed status (LCLS-Status IE) to a change in 
the BSS or it may be indicated as request to change the LCLS-Status (LCLS-Status-Change IE) due to handover or 
supplementary service invocation for example. 

The LCLS-Status IE can indicate the following statuses: 

- the call is LCLS connected 

- the call is not LCLS connected 

- the call is LCLS feasible but not yet connected 

The LCLS-Status-Change IE can indicate the following statuses: 

- LCLS is to be released 

- LCLS is to be released due to handover 

- LCLS is to be re-connected after LCLS break 

The MSC Servers shall only generate or forward the LCLS Status IE through the CN if there is a change to the current 
CN status (i.e. there is not a one to one mapping of the LCLS-BSS Status and the LCLS Status in the CN). The usage of 
these elements: the LCLS Status IE signalled in the LCLS_STATUS_UPDATE message and the LCLS-Status-Change 
IE which is signalled in the LCLS_STATUS_CHANGE_REQUEST message and 
LCLS_STATUS_CHANGE_REQUEST ACKNOWLEDGEMENT message is further detailed in sub-clause 16.1. 

4.6 User Plane when LCLS is Active 
4.6.1 General 

When LCLS has been established for a call, the voice data on the user plane is locally switched within the BSS. When 
the call is locally switched the core network shall assume that no user plane data will be received from the BSS for the 
duration of the locally switched call unless explicitly requested via the LCLS -Configuration IE. 

When user plane data is required to be inserted by the core network, e.g. supplementary services, unless previously 
negotiated via the LCLS -Negotiation IE (see sub-clause 4.2) an LCLS Break procedure shall precede the insertion of 
user plane data. 

NOTE: During Handover procedures and LCLS Break procedures, the BSS may start to send the user plane data 
to the core network before all nodes in the routing path have updated their related LCLS status, see 
clauses 7 and 8. 
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4.6.2 LCLS Configuration 



LCLS configuration is required in order to allow the Core Network to indicate to the BSS the LCLS connection 
preference. 

The LCLS Configuration Information Element is explicitly signalled on the A interface on a per call leg basis during 
Call Establishment and Handover procedures or at any time during the call using the LCLS_CONNECT_CONTROL 
message. See clauses 6 and 8 respectively. It is used to indicate if the local call shall be: 

- connected both- way in the BSS (basic LCLS connection) 

- connected both- way in the BSS and bi-casted UL to the Core Network 

- connected both- way in the BSS and send access DL from the Core Network (BSS may combine or replace local 
DL data with DL data from the Core Network) 

connected both- way in the BSS and send access DL from the Core Network, block local DL 

- connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network (BSS may combine or replace local DL data with DL data from the Core Network) 

- connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network, block local DL (BSS shall block local DL data but continue send UL data locally) 

If the BSS does not support a certain configuration this shall be indicated in the LCLS-BSS-Status IE to the MSC 
Server. 

The usage of the LCLS Configuration IE is further detailed in sub-clause 16.3. 



5 General Circuit Switched Core Network Domain 

Architecture 

LCLS does not require any modifications to the basic reference architecture. The General CS core network domain 
architecture is specified in 3GPP TS 23.205 [2]. Network Architecture for CS Core Network Nodes and GSM/EDGE 
Radio Access Networks is specified in 3GPP TS 23.002 [8]. 

NOTE: LCLS does introduce a number of conceptual changes as described in sub-clause 4.1. 



6 Call Establishment 

6.1 Basic Mobile Originating Call 

6.1 .1 Basic Mobile Originating Call with BICC based CS core network 

6.1.1.1 General 

The basic mobile originating call shall be established in accordance with 3GPP TS 23.205 [2]. The LCLS establishment 
may use forward or backward bearer establishment. The following sub-clauses describe the additional requirements 
related to the LCLS functionality. 

6.1.1.2 Initial Addressing 

If the oMSC server supports the LCLS feature it shall generate a Global Call Reference (GCR) IE. The GCR IE is 
derived from the ITU-T Global Call Reference IE [5] and specified in detail in the clause 16 and in 3GPP TS 29.205 
[6]. If the serving radio access is GERAN the Call Reference ID field of the GCR IE contains the originating BSS ID. 
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The oMSC server shall then include the GCR IE and LCLS -negotiation IE indicating the preferences for LCLS as 
defined in the sub-clause 4.2, clause 16 and in 3GPP TS 29.205 [6], together with the Supported Codecs List IE for 
OoBTC as specified in 3GPP TS 23.153 [4] in the lAM message to the succeeding call control node. 

6.1 .1 .3 Access Bearer Assignment 

6.1 .1 .3.1 Assignment performed after LCLS Negotiation through Core Network 

On receipt of the APM from the succeeding MSC server containing the LCLS -Negotiation IE, indicating local call 
connection is permitted, the oMSC server shall continue with the basic call establishment and if the serving radio access 
is GERAN shall include the GCR IE and the LCLS -Configuration IE (which is derived from the LCLS -Negotiation IE) 
in the originating BSSAP Assignment Request message (see 3GPP TS 48.008 [7]). If the APM does not contain the 
LCLS -Negotiation IE then the oMSC server shall determine that LCLS is not supported end to end and shall continue 
the call estabUshment as described in 3GPP TS 23.205 [2]. 

If the serving radio access is UTRAN the oMSC server shall save the LCLS -Negotiation information but proceed with 
the call establishment as described in TS 23.205 [2]. 

6.1 .1 .3.2 Assignment performed before LCLS Negotiation 

After generation of the GCR IE the oMSC initiates the access bearer assignment on the originating side and includes the 
GCR IE and the preliminary LCLS -Configuration IE (the final configuration can be different due to the following 
LCLS negotiation through the core network) in the originating BSSAP Assignment Request message. 

6.1.1.3.3 oBSS behavior 

If the originating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the 
LCLS -Configuration IE the originating BSS shall store the GCR IE against the Assigned Call leg and shall check if it 
can support the requested LCLS -Configuration. The originating BSS shall report the outcome in LCLS-BSS-Status IE 
returned to the MSC server in the Assignment Complete message. 

If the originating BSS does not support LCLS then the GCR IE and the LCLS -Configuration IE will be ignored and no 
LCLS-BSS-Status IE will be returned in the Assignment Complete message. The oMSC server shall continue the call 
establishment as for a Non-LCLS call. 

6.1 .1 .4 Backward LCLS Negotiation 

At reception of an APM, ACM or CPG message with the LCLS -Negotiation IE the oMSC server shall check if a new 
value of the LCLS -Negotiation IE requires the change of the requested LCLS configuration and if so the oMSC server 
shall mark that the LCLS -Configuration IE needs to be sent in the BSSAP message LCLS Connect Control to the BSS, 
see sub-clause 6.1.1.5. If the new value of LCLS -Negotiation indicates "LCLS Not Allowed" then the oMSC Server 
shall not proceed with further LCLS signalling. 

At reception of an unsolicited APM message without LCLS Negotiation IE then the oMSC shall handle the APM but 
not change the LCLS -Configuration or any LCLS behaviour. 

NOTE: APM is used for other services or applications and need not include LCLS Configuration IE. 

6.1 .1 .5 LCLS Through-Connection 

If the originating BSS determines that the call is local and can be locally switched it shall not through-connect the two 
parties unless explicitly indicated to do so by receiving the LCLS -Connection-Status-Control IE set to "Connect" for 
both call legs. 

When the oMSC server receives the ANM from the succeeding MSC server with the LCLS -Status IE indicating "LCLS 
is feasible but not yet connected" it shall send the BSSAP message LCLS-Connect-Control to the originating BSS 
containing the LCLS -Connection-Status-Control IE set to "Connect". If the value of the required LCLS Configuration is 
not the same as the value requested within the Assignment Request message, the oMSC Server shall also include the 
LCLS Configuration IE in the LCLS-Connect-Control message. 
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If the BSS has received the LCLS -Connection-Status-Control IE set to "Connect" for both call legs associated to the 
LCLS call it shall locally switch the user plane between the two call legs and report the through-connection via the 
LCLS -BSS -Status IE in the LCLS-Connect-Control Acknowledge message. The CN user plane shall be kept through- 
connected as described in the sub-clause 4.6. 

If the call is not yet locally switched when returning the LCLS-Connect-Control Acknowledge message but becomes 
locally switched at a later time (for example due to the LCLS -Connection-Status-Control IE requesting "Connect" at the 
second call leg) the BSS shall report the change in status via the LCLS -BSS -Status IE within the LCLS -Notification 
message as specified in 3GPP TS 48.008 [7]. 

NOTE: This should not occur at the oMSC server for normal call establishment as the oMSC server should 
always be the last (second) node sending the LCLS-Connect-Control message to the BSS. 

6.1 .1 .6 LCLS Status Reporting 

When the oMSC server receives the LCLS-Connect-Control Acknowledge message from the originating BSS with the 
LCLS -BSS -Status IE set to "the call is locally switched" it shall inform the succeeding MSC server with the APM 
message containing the LCLS Status IE set to "LCLS connected". 

During the LCLS call establishment and ongoing call any change to the LCLS connection status is reported by the BSS 
to the core network and only if it results in a change of the LCLS status in the core network, the updated LCLS status 
shall be signalled by the oMSC server to the succeeding nodes. See also sub-clause 4.5. 

6.1.1.7 MGW/User plane 

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2]. 

6.1 .2 Basic Mobile Originating Call with SIP-I based CS core network 

6.1.2.1 General 

The basic mobile originating call shall be established in accordance with 3GPP TS 23.231 [3]. The LCLS principles 
introduced in the sub-clause 6.1.1 for BICC protocol messages should also apply to SIP-I signalling cases. 

6.1.2.2 Initial Addressing 

The oMSC server shall send the initial SIP-I INVITE request with the GCR IE and LCLS -negotiation IE included 
within the encapsulated lAM message if the LCLS feature is supported. If an access bearer assignment has not been 
completed the initial SDP offer shall indicate that the local preconditions have not been met. 

6.1 .2.3 Access Bearer Assignment 

On receipt of the SIP-I 183 Session Progress provisional response from the succeeding MSC server containing the 
LCLS -Negotiation IE included within the encapsulated APM message, the oMSC server shall continue with the basic 
call establishment as specified in the sub-clause 6.1.1.3. 

6.1 .2.4 Backward LCLS Negotiation 

At reception of the SIP-I 183 Session Progress provisional response with the LCLS -Negotiation IE included within the 
encapsulated APM message the oMSC server shall check the value of the LCLS -Negotiation IE as specified in the sub- 
clause 6.1.1.4. 

6.1 .2.5 LCLS Through-Connection 

On the reception of the 200 OK final response to the initial INVITE with the encapsulated ANM message containing 
LCLS-Status IE the oMSC server shall apply the LCLS Through-Connection procedure specified in the sub-clause 
6.1.1.5. 
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6.1 .2.6 LCLS Status Reporting 

The oMSC server shall send the SIP-I INFO request containing the LCLS Status IE included within the encapsulated 
APM message to the succeeding MSC server when LCLS Status Reporting needs to be performed according to 
procedure described in the sub-clause 6. LI. 6. 

6.1.2.7 MGW/User plane 

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2]. 

6.2 Basic Mobile Terminating Call 

6.2.1 Basic Mobile Terminating Call with BICC based CS core network 

6.2.1.1 General 

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.205 [2]. The LCLS establishment 
may use forward or backward bearer establishment. The following sub-clauses describe the additional requirements 
related to the LCLS functionality. 

6.2.1 .2 Actions at Intermediate Nodes (including GMSC) 

6.2.1.2.1 Initial Addressing 

If an intermediate node supports the LCLS feature and receives the LCLS -Negotiation IE from a preceding node in the 
lAM it may modify the preferences based on its own requirements, and shall then forward the resulting LCLS- 
Negotiation IE to the succeeding node. The rules for modifying the LCLS -Negotiation IE preferences are specified in 
the sub-clause 4.2. 

If LCLS is not permitted by the intermediate node based on LCLS -Negotiation preference then it shall not forward the 
LCLS -Negotiation IE and GCR to the succeeding node. 

6.2.1 .2.2 Backward LCLS Negotiation 

If the intermediate node supports the LCLS feature and has sent the GCR IE and LCLS -Negotiation IE within I AM 
message towards the succeeding node further action depends on the content of the first received backward message 
(APM message or ACM). 

If the intermediate node receives the first backward message (APM or ACM) without the LCLS -Negotiation IE 
it should include the LCLS -Negotiation IE indicating "LCLS not allowed" into APM/ ACM before forwarding 
the APM/ ACM to the preceding node. 

NOTE: This indicates to preceding nodes that the requested LCLS configuration was not accepted. If the 
intermediate node does not include any LCLS -Negotiation result then it implicitly indicates to the 
preceding node that LCLS feature is not supported. 

- When the received APM/ ACM contains the LCLS -Negotiation IE then the forwarding MSC server shall forward 
the received LCLS -Negotiation IE to the preceding node. 

If the intermediate node supports the LCLS feature and has sent the I AM message without GCR IE and LCLS- 
Negotiation IE (configuration not permitted), it should include the LCLS -Negotiation IE indicating "LCLS not allowed" 
into APM/ ACM before forwarding the APM/ ACM to the preceding node. 

NOTE: This indicates to preceding nodes that the requested configuration was not accepted. If the intermediate 
node does not include any LCLS -Negotiation result then it implicitly indicates to the preceding node that 
LCLS feature is not supported. 

If the intermediate node has not forwarded LCLS -Negotiation IE in any previous APM/ ACM message and receives an 
APM which does not include LCLS Negotiation IE then the intermediate node shall handle the APM but shall not 
include any LCLS lE's when passing on such APM's; no changes to LCLS status shall result. 
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NOTE: APM is used for other services or applications and need not include LCLS Configuration IE. 
Other information elements shall be treated as specified in 3GPP TS 23.205 [2] and in 3GPP TS 23.231 [3]. 

6.2.1 .2.3 Through-Connection 

The procedure specified in 3GPP TS 23.205 [2] shall be applied. 

6.2.1 .2.4 LCLS Status Reporting within CN 

If the LCLS status is received from its adjacent node, the MSC server shall update the LCLS status and shall pass on to 
the next node only if the LCLS status has changed. See also sub-clause 4.5. 

6.2.1.2.5 MGW/User plane 

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2]. 

6.2.1 .3 Actions at Ternninating Gall side 

6.2.1.3.1 Initial Addressing 

If the tMSC server supports LCLS feature and receives the GCR IE and the LCLS -Negotiation IE it may modify the 
preferences based on its own requirements. The rules for modifying the LCLS -Negotiation IE preferences are specified 
in the clause 4.2 and in 3GPP TS 29.205 [6]. 

6.2.1 .3.2 Backward LCLS Negotiation 

If the tMSC server supports LCLS feature then it shall return the final LCLS -Negotiation IE to the preceding node in 
the APM or the ACM message. 

6.2.1 .3.3 Access Bearer Assignment 

If the serving radio access is GERAN then when the tMSC server performs the access bearer assignment it shall include 
the GCR IE and the LCLS -Configuration IE (which is derived from the LCLS -Negotiation IE) in the BSSAP 
Assignment Request message sent to the terminating BSS (see 3GPP TS 48.008 [7]). 

If the tMSC server supports the optional "intra-Network call detection" procedure and determines that the Network ID 
within the GCR IE is not equal to the own (tMSC) Network ID, the tMSC server shall also include the "LCLS- 
Correlation-Not-Needed" IE in the Assignment Request message (see sub-clause 4.3.2). 

If the tMSC server supports the optional "intra-BSS call detection" procedure and determines that the BSS ID within the 
GCR IE is not equal to the terminating BSS ID, the tMSC server shall also include the "LCLS -Correlation-Not-Needed" 
IE in the Assignment Request message (see sub-clause 4.3.3). 

If the terminating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the 
LCLS -Configuration IE, the BSS shall store the GCR against the Assigned Call leg and check if it can support the 
requested LCLS -Configuration. Unless the BSS supports the optional "intra-Network call detection" procedure (see 
sub-clause 4.3.2) or optional "intra-BSS call detection" procedure (see sub-clause 4.3.3) it shall perform a correlation of 
the received GCR to see if another call leg has been assigned with the same GCR and report the outcome in the LCLS- 
BSS-Status IE returned to the tMSC server in the Assignment Complete message. 

If the terminating BSS does not support LCLS then the GCR IE and the LCLS -Configuration IE will be ignored and no 
LCLS -BSS -Status IE will be returned in the Assignment Complete message. The tMSC server shall continue the call 
establishment as for normal Non-LCLS call. 

6.2.1 .3.4 LCLS Through-Connection 

If the terminating BSS determines that the call is local and can be locally switched it shall not through-connect the two 
parties unless explicitly indicated to do so by receiving the LCLS -Connection-Status-Control IE set to "Connect" for 
both call legs. 
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When the tMSC server receives "answer" from the terminating UE it shall send the BSSAP message LCLS-Connect- 
Control containing the LCLS-Connection-Status-Control IE set to "Connect" and send the ANM message with the 
LCLS-Status IE indicating "LCLS is feasible but not yet connected" to the preceding MSC server. 

If the BSS has received the LCLS -Connection-Status-Control IE set to "Connect" for both call legs associated to the 
LCLS call it shall locally switch the user plane between the two call legs and report the through-connection via LCLS- 
BSS-Status IE in the LCLS-Connect-Control Acknowledge message. The CN user plane shall be kept through- 
connected as described in the sub-clause 4.6. 

If the call is not yet locally switched when returning the LCLS-Connect-Control Acknowledge message but becomes 
locally switched at a later time (for example due to the LCLS -Connection-Status-Control IE requesting "Connect" at the 
second call leg) the BSS shall report the change in status via LCLS -BSS -Status IE within the LCLS -Notification 
message as specified in 3GPP TS 48.008 [7]. 

6.2.1 .3.5 LCLS Status Reporting 

During the LCLS call establishment and ongoing call any change to the LCLS connection status is reported by the BSS 
to the core network and only if it results in a change of the LCLS status in the core network the updated LCLS status 
shall be signalled by the tMSC server to the preceding node. See also sub-clause 4.5. 

6.2.1.3.6 MGW/User plane 

The MGW/user plane shall be estabUshed in accordance with 3GPP TS 23.205 [2]. 

6.2.2 Basic Mobile Terminating Call with SIP-I based CS core network 

6.2.2.1 General 

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.231 [3]. The LCLS principles 
using introduced in the sub-clause 6.2.1 for BICC protocol messages should also apply to SIP-I signalling cases. 

6.2.2.2 Actions at Internnediate Nodes (including GMSG) 

6.2.2.2.1 Initial Addressing 

If an intermediate node supports the LCLS feature and receives the LCLS -Negotiation IE included within the 
encapsulated lAM message from a preceding node in the SIP-I INVITE request it may modify the LCLS -Negotiation IE 
based on its own requirements, and shall then forward the initial INVITE request with the resulting LCLS -Negotiation 
IE included within the encapsulated lAM message to the succeeding node. 

6.2.2.2.2 Backward LCLS Negotiation 

On the receipt of the 183 Session Progress provisional response the intermediate node shall apply the Backward LCLS 
Negotiation procedure specified in the sub-clause 6.2.1.2.2. 

6.2.2.2.3 Through-Connection 

See sub-clause 6.2.1.2.3. 

6.2.2.2.4 LCLS Status Reporting within CN 

See sub-clause 6.2.1.2.4. 

6.2.2.2.5 MGW/User plane 

See sub-clause 6.2.1.2.5. 
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6.2.2.3 Actions at Terminating Call side 

6.2.2.3.1 Initial Addressing 

See sub-clause 6.2.1.3.1. 

6.2.2.3.2 Backward LCLS Negotiation 

If the tMSC server supports LCLS feature then it shall return the final LCLS -Negotiation IE included within the 
encapsulated APM message to the preceding node in the SIP-I 183 Session Progress provisional response. 

6.2.2.3.3 Access Bearer Assignment 

See sub-clause 6.2.1.3.3. 

6.2.2.3.4 LCLS Through-Connection 

The tMSC server shall apply the LCLS Through-Connection procedure specified in the sub-clause 6.2.1.3.4. The 
LCLS -Status IE indicating "LCLS is feasible but not yet connected" shall be included in the ANM message 
encapsulated in the 200 OK final response to the initial INVITE. 

6.2.2.3.5 LCLS Status Reporting 

See sub-clause 6.2.1.3.5. 

6.2.2.3.6 MGW/User plane 

See sub-clause 6.2.1.3.6. 

6.3 Basic Mobile to Mobile End to End Call Examples 
6.3.1 Basic Call Establishment Connection Model for LCLS 

Figure 6.3.1.1 shows the network model for the basic call establishment for a Local Call. The oMSC server seizes one 
context with two bearer terminations in the oMGW. The bearer termination Tl is used for the bearer towards the oBSS 
and the bearer termination T2 is used for the bearer towards the iMSC selected iMGW. The iMSC server seizes one 
context with two bearer terminations in the iMGW. The bearer termination T6 is used for the bearer towards the tMSC 
server selected tMGW and the bearer termination T5 is used for the bearer towards the preceding oMGW. The tMSC 
server seizes one context with two bearer terminations in the tMGW. The bearer termination T3 is used for the bearer 
towards the iMSC selected iMGW and bearer termination T4 is used for the bearer towards the tBSS. 
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Connection Model 1 : After Alerting, Backward Through Connection 
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6.3.2 



Connection Model 2: After answer, Call is locally switched 
Figure 6.3.1.1: Basic Call Establishment Connection Model for Local Call 

LCLS established, Basic Call Example with BICC based CS core 
network, forward bearer establishment 



Figures 6.3.2.1, 6.3.2.2 and 6.3.2.3 show the message sequence example for the basic call establishment for LCLS. In 
this example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and the CN permits LCLS. The 
example is based on examples from 3GPP TS 23.205 [2] for the basic mobile originating call, forward bearer 
establishment (case when access bearer assignment is requested on the originating side after reception of Bearer 
Information message) and the basic mobile terminating call, forward bearer establishment. 
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Figure 6.3.2.1 : Basic Call Establishment Flow when call is locally switched, forward bearer 

establishment 

Service Request handling. 

Originating Call SETUP. 

The oMSC server replies with the CALL PROCEEDING message to indicate that the call is being processed. 

If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

The oMSC server sends the lAM message including supported codecs list, GCR with encapsulated oBSS ID, 
and configures the LCLS-Negotiation IE. 

If the iMSC server supports LCLS it may modify the LCLS-Negotiation IE due to CAMEL, supplementary 
service requirements etc. before sending the lAM message containing the GCR with the encapsulated oBSS 
ID and the LCLS-Negotiation IE. 

The tMSC server pages the tUE. 

The tMSC server performs call Setup. 

The tUE confirms the call. 

The tMSC server requests the tMGW to prepare for the network side bearer establishment. 
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10. After the tMGW has repHed with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec, available codec list and if LCLS is supported, the LCLS -Negotiation 
IE. 

11a. When the bearer information is received the iMSC server requests the seizure of the outgoing network side 
bearer termination. 

1 lb. After the outgoing side bearer termination is seized the iMSC server requests the seizure of the incoming 
network side bearer termination. 

During the seizure of the outgoing side and the incoming side bearer termination the iMSC server will also 
request the iMGW to through-connect the bearer terminations so that the bearer will be bothway through- 
connected. 

12. The iMSC server transfers the APM message with the selected codec, available codec list and the LCLS- 
Negotiation IE. 

13a. When the bearer information is received the oMSC server requests the seizure of the network side bearer 
termination. 

13b. After the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination. 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 
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Figure 6.3.2.2: Basic Call Establishment when call is locally switched, forward bearer establishment 

(continuation of figure 6.3.2.1) 
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14. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

15. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

16. When the access assignment is completed the oMSC server sends the Continuity (COT) message to the 
iMSC server. 

17. The iMSC server transfers the COT message to the tMSC server. 

18. The tMSC server requests the seizure of the access side bearer termination. If not requested during the 
seizure of network side bearer termination (step 9b) the tMSC server will request the tMGW to through- 
connect the bearer terminations so that the bearer will be backward through-connected. 

19a. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 

19b. The tMSC server performs the access bearer assignment and sends the ASSIGNMENT REQUEST message 
containing the GCR IE and the LCLS -Configuration IE if LCLS is permitted in the core network. 

20. The oBSS/tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra 
BSS call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

20a. Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 

oBSS signals the LCLS status change by sending the LCLS_NOTIFICATION message with the LCLS-BSS- 
Status IE set to "Call not yet locally switched". 

2 1 . The tUE reports alerting. 

22a, b. The tMSC server returns the ACM message and requests the tMGW to provide a ring-back tone. 

23. The iMSC server transfers the ACM message to the oMSC server. 

24. The oMSC server reports alerting. 
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Figure 6.3.2.3: Basic Call Establishment when call is locally switched, forward bearer establishment 

(continuation of figure 6.3.2.2) 

25. The tUE answers the call. 

25a. The tMSC server returns the CONNECT ACKNOWLEDGE message to the tUE. 

26. The tMSC server indicates to the tBSS that this call leg is ready to be locally switched by sending the 
LCLS_CONNECT_CONTROL message (note the BSS cannot through-connect LCLS until it receives the 
same indication from the oMSC server). 

27. The tBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to 
"Call not yet locally switched" since the BSS has not received the same order from the oMSC server. 

28. When the tMSC server receives the Connect message it requests the tMGW to stop providing ring-back tone 
to the calling party and requests to bothway through-connect the bearer. 

29. The tMSC server returns the ANM message with the LCLS-Status IE indicating "LCLS is feasible but not yet 
connected" . 

30. The oMSC server receives the ANM message with the LCLS-Status IE indicating "LCLS is feasible but not 
yet connected" . 
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3 1 . The oMSC server request the oMGW to both way through-connect the bearer. 

32. The oMSC server reports Answer/Connect to the oUE. 

32a. The oUE completes the call establishment with the CONNECT ACKNOWLEDGE message. 

33. The oMSC server requests the oBSS to connect LCLS since the received ANM message indicated "LCLS is 
feasible but not yet connected". 

34a. Since the BSS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "call is locally 
switched" . 

NOTE 1 : If the BSS cannot locally through-connect the call at this time then it is indicated by setting the 
LCLS -BSS -Status IE set to "the call is not yet locally switched". If at a later time the BSS can 
locally switch the call, this is indicated by sending the LCLS_NOTIFICATION message with the 
LCLS-BSS-Status IE set to "the call is locally switched". 

34b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS-BSS-Status IE set to "call is locally 
switched" . 

34c. If the oMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no succeeding node requires the UL 
data from the oUE then the oMSC server requests the oMGW to isolate the access side termination Tl from 
the network side termination T2. 

34d. If the tMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no preceding node requires the UL 
data from the tUE then the tMSC server requests the tMGW to isolate the access side termination T4 from 
the network side termination T3. 

NOTE 2: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

35. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

36. The iMSC server transfers the change of the LCLS status to the tMSC server. 

6.3.3 LCLS not established, Basic Call Example with BICC based CS core 
network 

The Figure 6.3.3.1 shows the message sequence example for the basic call establishment for LCLS when the call could 
not be locally switched. In this example the CN permits LCLS but the oUE and the tUE belong to different BSS's 
(marked as oBSS and tBSS). The example is based on examples from 3GPP TS 23.205 [2] for the basic mobile 
originating call, forward bearer establishment and the basic mobile terminating call, forward bearer establishment. 
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For preceding signaling sequences for basic call setup steps 1- 18 see figures 6.3.2.1 and 6.3.2.2 
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Figure 6.3.3.1 : Basic Call Establishment Flow when call is not locally switched 

1-18. The basic call establishment procedure between the UE-1 and the UE-2 is the same as specified in steps 1-18 
of sub-clause 6.3.2.1. 

19a. If the tMSC server supports the optional "Intra-Network Call Detection" procedure it may compare its own 
Network ID with the Network ID received within the Global Call Reference (GCR) IE. 
If the tMSC server supports the optional "Intra-BSS Call Detection" procedure it may compare the BSS ID of 
the selected terminating BSS with the value of the originating BSS ID received within the GCR IE at this 
step. 

In this case, the result of the "Intra-Network Call Detection" procedure or "Intra-BSS Call Detection" 
procedure is that the call is not an intra-Network or an intra-BSS call. 

19b. The tMSC server performs the terminating access bearer assignment and sends the ASSIGNMENT 

REQUEST message containing the GCR IE and the LCLS-Configuration IE if LCLS is permitted in the core 

network. 

If the tMSC server performed the "Intra-Network Call Detection" procedure in step 19a and/or the tMSC 

server performed the "Intra-BSS Call Detection" procedure in step 19a, then the tMSC server includes the 

"LCLS-Correlation-Not-Needed" IE in the ASSIGNMENT REQUEST message since the oUE and the tUE 

belong to the different BSS's. 

20. The tBSS returns the ASSIGMENT COMPLETE message with the LCLS -BSS -Status IE indicating "Call 
Not Possible to be Locally Switched". 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 



39 



ETSI TS 123 284 VI 0.1.0 (2011-06) 



21 - 30.The basic call establishment procedure between the UE-1 and the UE-2 continues as for the normal, non- 
LCLS call. 



6.3.4 LCLS established, Basic Call Example with SIP-I based CS core 
network 

Figures 6.3.4.1, 6.3.4.2, 6.3.4.3 and 6.3.4.4 show the message sequence example for the basic call establishment when 
call is locally switched. In this example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and 
the CN permits LCLS. The example is based on examples for the basic mobile originating call and for the basic mobile 
terminating call from 3GPP TS 23.231 [3]. 
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Figure 6.3.4.1 : Basic Call Establishment Flow when call is locally switched 

Service Request handling. 

Originating Call SETUP. 

The oMSC server replies with a CALL PROCEEDING message to indicate that the call is being processed. 

If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

The oMSC server selects the codec and requests the oMGW to select and provide the IP transport address 
and port for the network side bearer connection before sending the INVITE message. 
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6. The oMSC server sends the INVITE request with the initial SDP offer indicating that local preconditions 
have not been met, and with the encapsulated lAM message containing the GCR with encapsulated oBSS ID, 
and the LCLS -Negotiation IE. 

7. The iMSC server confirms the reception of the INVITE request with a 100 Trying provisional response. 

8. The iMSC server selects the codec and requests the iMGW to select and provide the IP transport address and 
port for the outgoing network side bearer termination. 

9. If the iMSC server supports LCLS it may modify the LCLS -Negotiation IE due to CAMEL, supplementary 
service requirements etc. before sending the INVITE request with the SDP offer and with the encapsulated 
lAM message containing the GCR with the encapsulated oBSS ID and the LCLS -Negotiation IE. 

10. The tMSC server confirms the reception of the INVITE request with 100 a Trying provisional response. 

1 1 . The tMSC server pages the tUE. 

12. The tMSC server performs call Setup. 

13. The tUE confirms the call. 

14. The tMSC server selects the codec, provides to the tMGW the selected codec and the remote user plane IP 
address and port information that were received from the preceding node in the SDP offer and requests the 
tMGW to prepare for the network side bearer establishment. 

15. After the tMGW has replied with the local IP address and port information the tMSC server includes in the 
SDP answer the user plane IP address and UDP port received from the tMGW, the selected codec and any 
additional accepted payload types. The tMSC server returns a 183 Session Progress provisional response with 
the SDP answer and if LCLS is supported with encapsulated APM message containing the LCLS -Negotiation 
IE. 

16. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 183 
Session Progress provisional response. 

17. When the 183 Session Progress provisional response with the SDP answer is received the iMSC server 
requests the iMGW to configure the remote IP transport address and any additional negotiated payload types 
of the outgoing side bearer termination. 

18. The tMSC server confirms the reception of the PRACK request with a 200 OK final response. 
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NOTE: ForAoTDM 
step 31 is: ADD (T4). 



19. The iMSC server selects the codec for the incoming side bearer termination, provides to the iMGW the 
selected codec and the remote user plane IP address and port information that were received from the 
preceding node in the SDP offer and requests the iMGW to prepare for the incoming side bearer 
establishment. 

During the seizure of the outgoing side and the incoming side bearer termination the iMSC server will also 
request the iMGW to through-connect the bearer terminations so that the bearer will be bothway through- 
connected. 

20. After the iMGW has replied with the local IP address and port information the iMSC server includes in the 
SDP answer the user plane IP address and UDP port received from the iMGW, the selected codec and any 
additional accepted payload types. The iMSC server sends the 183 Session Progress provisional response 
with the SDP answer and with encapsulated APM message containing the LCLS -Negotiation IE to the 
preceding node. 

21. The oMSC server replies to the succeeding node with the PRACK request to confirm the reception of the 183 
Session Progress provisional response. 

22. The oMSC server requests the oMGW to configure the remote user plane IP address and any additional 
negotiated payload types of the network side bearer termination. 

23. The oMSC server requests the seizure of the access side bearer termination. 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 
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24. The iMSC server confirms the reception of the PRACK request with the 200 OK final response. 

25. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

26. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS-BSS-Status IE indicating "call 
not possible to be locally switched". 

27. When the oMSC server receives the ASSIGNMENT COMPLETE message, it requests the oMGW to 
configure the remote user plane IP address and UDP Port for the access side bearer termination. 

28. Since the access bearer assignment is completed the oMSC server sends the UPDATE request with the SDP 
offer indicating local preconditions met to the succeeding node. 

29. The iMSC server forwards the UPDATE request to the succeeding node. 

30. The tMSC server confirms the reception of the UPDATE request with the 200 OK final response. 

31. When the tMSC server receives the SDP offer indicating remote preconditions met it requests the seizure of 
the access side bearer termination. 

If not requested during the seizure of network side bearer termination (step 14) the tMSC server will request 
the tMGW to through-connect the bearer terminations so that the bearer will be backward through-connected. 

32. The iMSC server forwards the 200 OK (UPDATE) final response to the preceding node. 

33. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the ESS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 
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34. The tMSC server sends the ASSIGNMENT REQUEST message containing the GCR IE and the LCLS- 
Configuration IE if LCLS is permitted in the core network. 

35. a) The tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra BSS 
call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

b) Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 
oBSS signals the LCLS status change to the oMSC server by sending the LCLS_NOTIFICATION message 
with the LCLS -BSS -Status IE set to "Call not yet locally switched". 

36. The tUE reports alerting. 

37. The tMSC server requests the tMGW to provide a ring-back tone. 

38. The tMSC server sends a 180 Ringing provisional response with the encapsulated ACM message to the 
preceding node. 

39. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 
Ringing provisional response. 

40. The iMSC server transfers the 180 Ringing provisional response with the encapsulated ACM message to the 
preceding node. 
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41. The oMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 
Ringing provisional response. 

42. The tMSC server confirms the reception of the PRACK request with the 200 OK final response. 

43. The oMSC server reports alerting. 

44. The IMSC server confirms the reception of the PRACK request with the 200 OK final response. 

45. The tUE answers the call. 

46. The tMSC server returns the CONNECT ACKNOWLEDGE message to the tUE. 

47. The tMSC server indicates to the tBSS that this call leg is ready to be locally switched by sending the 
LCLS_CONNECT_CONTROL message. 

48. The tBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to 
"Call not yet locally switched" since the BSS has not received the same order from the oMSC server. 

49. When the tMSC server receives the Connect message it requests the tMGW to stop providing ring-back tone 
to the calling party and requests to bothway through-connect the bearer. 

50. The tMSC server returns the 200 OK (INVITE) final response with the encapsulated ANM message with the 
LCLS-Status IE indicating "LCLS is feasible but not yet connected". 

5 1 . The oMSC server receives the 200 OK (INVITE) final response with the encapsulated ANM message with 
the LCLS-Status IE indicating "LCLS is feasible but not yet connected". 
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52. The oMSC server replies to the succeeding node with the ACK request to confirm the reception of the 200 
OK final response. 
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53. The oMSC server request the oMGW to both way through-connect the bearer. 

54. The iMSC server transfers the ACK request to the succeeding node. 

55. The oMSC server reports Answer/Connect to the oUE. 

56. The oUE returns the CONNECT ACKNOWLEDGE message to the oMSC server. 

57. The oMSC server requests the oBSS to connect LCLS since the received 200 OK (INVITE) final response 
indicated "LCLS is feasible but not yet connected". 

58. a) Since the BSS has received the through connect request for both call legs the oBSS returns the 
LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "call is locally 
switched" . 

b) The tBSS signals the LCLS status change to the tMSC server by sending the LCLS_NOTIFICATION 
message with the LCLS-BSS-Status IE set to "call is locally switched". 

c) If the oMSC server supports the option to configure its Access MGW to isolate the access side 
termination from the network side termination and LCLS negotiation indicated that no succeeding node 
requires the UL data from the oUE then the oMSC server requests the oMGW to isolate the access side 
termination Tl from the network side termination T2. 

d) If the tMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no preceding node requires the UL 
data from the tUE then the tMSC server requests the tMGW to isolate the access side termination T4 from 
the network side termination T3. 

NOTE: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

59. The oMSC server signals the change of the LCLS status through the Core Network by sending the INFO 
request with the encapsulated APM message with the LCLS-Status IE set to "LCLS connected". 

60. The iMSC server returns the 200 OK (INFO) final response to the preceding node. 
6L The iMSC server transfers the change of the LCLS status to the succeeding node. 
62. The tMSC server returns the 200 OK (INFO) final response to the preceding node. 

6.3.5 LCLS established, Basic Call Example with BICC based CS core 
network, backward bearer establishment 

Figures 6.3.5.1 and 6.3.5.2 show the message sequence example for the basic call establishment for LCLS. In this 
example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and the CN permits LCLS. The 
example is based on examples from 3GPP TS 23.205 [2] for the basic mobile originating call, backward bearer 
establishment (case when access bearer assignment is completed before sending of initial address message) and the 
basic mobile terminating call, backward bearer establishment. 
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Figure 6.3.5.1 : Basic Call Establishment Flow when call is locally switched, backward bearer 

establishment 

1. Service Request handling. 

2. Originating Call SETUP. 

3. The oMSC server replies with the CALL PROCEEDING message to indicate that the call is being processed. 

4. If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

5. Before the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination. 

6. The oMSC server includes a preHminary LCLS -Configuration IE in the ASSIGNMENT REQUEST message 
along with the GCR IE, because the oMSC server does not know whether LCLS is allowed in the core 
network at this stage. 

7. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

8. The oMSC server prepares the seizure of the network side bearer termination. 
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9. Afer the oMGW has repHed with the bearer address and the binding reference, the oMSC server sends the 
lAM to the succeeding node, in which the oMSC server indicates that backward bearer estabUshment is to be 
used. The oMSC server sends the lAM message including supported codecs Hst, GCR with encapsulated 
oBSS ID, and configures the LCLS -Negotiation IE. 

10. When the initial address and the bearer information is received the iMSC server requests the seizure of the 
network side bearer termination. 

1 1 . The iMSC server prepares the seizure of the outgoing side bearer termination. 

12. Afer the iMGW has replied with the bearer address and the binding reference, the iMSC server sends the 
lAM to the succeeding node. If the iMSC server supports LCLS it may modify the LCLS -Negotiation IE due 
to CAMEL, supplementary service requirements etc. before sending the I AM message containing the GCR 
with the encapsulated oBSS ID and the LCLS -Negotiation IE. 
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27. For succeeding signalling sequence see figure 6.3.2.3. 
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Figure 6.3.5.2: Basic Call Establishment when call is locally switched, backward bearer 
establishment (continuation of figure 6.3.5.1) 

1 3 . The tMSC server pages the tUE. 

14. The tMSC server performs call Setup. 

15. The tUE confirms the call. 
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16. The tMSC server requests the tMGW to estabUsh a bearer to the given iMGW. 

17. The tMSC server requests the seizure of the access side bearer termination. 

18. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 

19. The tMSC server performs the access bearer assignment and sends the ASSIGNMENT REQUEST message 
containing the GCR IE and the LCLS -Configuration IE if LCLS is permitted in the core network. 

20. The oBSS/tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra 
BSS call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

21. Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 
oBSS signals the LCLS status change by sending the LCLS_NOTIFICATION message with the LCLS-BSS- 
Status IE set to "Call not yet locally switched". 

22. The tUE reports alerting. 

23. The tMSC server returns the ACM message and includes the LCLS -Negotiation IE if LCLS is supported. 

24. The tMSC requests the tMGW to provide a ring-back tone. 

25. The iMSC server returns the ACM message and includes the LCLS -Negotiation IE. 

26. The oMSC server reports alerting. 

27. When performing further call establishment see figure 6.3.2.3. 



Call Clearing and LCLS Break/Re-establishment 



7.1 Call Clearing 



The call clearing procedures shall be performed in accordance with 3GPP 23.205 [2] for a BICC based CS core network 
and in accordance with 3GPP TS 23.231 [3] for a SIP-I based CS core network. 

7.2 LCLS Break 

7.2.1 MSC server Initiated 
7.2.1.1 Principles 

When the MSC server determines that local switching should be disconnected: 

- it shall send a LCLS Status Change Request message indicating disconnection preparation through the Core 
Network. 

- on receipt of a LCLS Status Change Request Acknowledge message indicating disconnection preparation with a 
Result code indicating LCLS Status Change Request accepted the MSC server shall send a LCLS -Connection- 
Control message indicating LCLS break to the associated BSS. 

On receipt of the LCLS Status Change Request message indicating disconnection preparation the MSC server shall: 

- send a LCLS break request immediately to the associated BSS, and 
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- when the acknowledge message is received from the BSS, the MSC server shall return the LCLS Status Change 
Request Acknowledge message indicating disconnection preparation and a Result code indicating LCLS Status 
Change Request accepted. 

The BSS needs to receive the LCLS break request on both call legs before releasing local switching. 

7.2.1 .2 MSC server actions 

When the MSC server determines that local switching should be disconnected it shall send to the succeeding (or 
preceding) node the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS- 
Disconnection-Preparation" . 

On the reception of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request accepted, the MSC 
server shall send to the BSS the LCLS-Connect-Control message with the LCLS -Connection-Status-Control IE set to 
"Release LCLS". At reception of the LCLS-Connect-Control Acknowledge message with the LCLS -BSS -Status IE set 
to "Locally switched call is no longer locally switched", the MSC server shall send to the succeeding (or preceding) 
node the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" if the same LCLS Status 
Update message was not already received from the succeeding (or preceding) node. 

When the MSC server receives the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" it shall send to the BSS the LCLS-Connect-Control message with the LCLS- 
Connection-Status-Control IE set to "Release LCLS". On reception of the LCLS-Connect-Control Acknowledge 
message the MSC server shall send to the preceding (or succeeding) node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and a Result code 
IE indicating LCLS Status Change Request accepted. 

When the LCLS-Connect-Control Acknowledge or the LCLS -Notification message with the LCLS -BSS -Status IE set to 
"Locally switched call is no longer locally switched" is received, the MSC server shall send to the succeeding (or 
preceding) node the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" if the same 
LCLS Status Update message was not already received from the succeeding (or preceding) node. 

7.2.1 .3 GMSC server actions 

On receipt of the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection- 
Preparation" from the preceding (or succeeding) node, the GMSC Server shall forward message to the succeeding (or 
preceding) node. 

The GMSC Server shall forward the received LCLS Status Change Request Acknowledge message with the LCLS- 
Status-Change IE set to "LCLS -Disconnection-Preparation" and the Result code IE indicating LCLS Status Change 
Request accepted. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the GMSC Server shall forward the message to the succeeding (or preceding) node if the same request was not 
already received from the succeeding (or preceding) node. 

- the GMSC Server shall not forward the message if the same request was already received from the succeeding 
(or preceding) node. 

7.2.1.4 BSS actions 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "Release LCLS" 
the following applies: 

- if the request was received for only one call leg associated to the LCLS call, the BSS shall not break the local 
switching. The BSS shall only send the LCLS-Connect-Control Acknowledge message to the MSC server with 
LCLS-BSS-Status indicating LCLS is still estabHshed. 

- if the request was received for both call legs associated to the LCLS call, the BSS shall break local switching and 
shall report the LCLS disconnection on both call legs by sending: 
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- the LCLS-Connect-Control Acknowledge message to the MSC server and 

- the LCLS -Notification message to the far end MSC server which previously requested LCLS release for the 
associated leg. 

7.2.2 BSS Initiated 

7.2.2.1 Principles 

When the BSS determines that local switching should be disconnected it may: 

- immediately break local switching and then inform the Core Network, or 

- first request the Core Network to prepare for LCLS break and on the reception of LCLS break request on both 
call legs the BSS breaks local switching. 

7.2.2.2 Immediate LCLS break 

7.2.2.2.1 BSS actions 

When the BSS determines that local switching should be disconnected it shall immediately break local switching. The 
BSS shall report the LCLS disconnection by sending the LCLS -Notification message with the LCLS -BSS -Status IE set 
to "Locally switched call is no longer locally switched" to both MSC servers associated to the LCLS call. 

7.2.2.2.2 MSC server actions 

At reception of the LCLS -Notification message with the LCLS -BSS -Status IE set to "Locally switched call is no longer 
locally switched", the MSC server shall send to the succeeding (or preceding) node the LCLS Status Update message 
with the LCLS-Status IE set to "LCLS Not Connected" if the same LCLS Status Update message was not already 
received from the succeeding (or preceding) node. 

7.2.2.2.3 GMSC server actions 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the GMSC Server shall forward the message to the succeeding (or preceding) node if the same request was not 
already received from the succeeding (or preceding) node. 

- the GMSC Server shall not forward the message if the same request was already received from the succeeding 
(or preceding) node. 

7.2.2.3 BSS Requesting LCLS Release from Core Network 

7.2.2.3.1 BSS actions 

When the BSS determines that local switching should be disconnected but the LCLS release should be ordered from the 
Core Network the BSS shall request the LCLS disconnection by sending the LCLS -Notification message with a LCLS- 
Break-Request IE to both MSC servers associated to the LCLS call. 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "Release LCLS" 
the BSS shall apply the procedure described in sub-clause 7.2.1.4. 

7.2.2.3.2 MSC server actions 

At reception of the LCLS -Notification message with LCLS -Break-Request IE the MSC server shall send to the 
succeeding (or preceding) node the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation". 
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On the reception of the LCLS Status Change Request message with the LCLS -Status-Change IE indicating LCLS 
disconnection preparation, the MSC server shall apply the procedure described in sub-clause 7.2.1.2 with the following 
exception: 

- on the reception of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request 
accepted the MSC server shall not request the LCLS break if it already requested due to the reception of the 
LCLS Status Change Request message from the succeeding (or preceding) node. 

7.2.2.3.3 GMSC server actions 

The GMSC server shall perform the same actions as described in sub-clause 7.2. L3. 

7.2.3 Intermediate Node/GMSC Server Initiated 

7.2.3.1 Principles 

When an intermediate node or a GMSC server determines that local switching should be disconnected it shall send the 
LCLS Status Change Request message indicating disconnection preparation to the preceding and to the succeeding 
node. 

On receipt of LCLS Status Change Request message indicating disconnection preparation the originating or terminating 
MSC server shall send LCLS break request immediately to the associated BSS. When the acknowledge message is 
received from the BSS, the MSC server shall return LCLS Status Change Request Acknowledge message indicating 
disconnection preparation and a Result code indicating LCLS Status Change Request was accepted. 

The BSS needs to receive the LCLS break request on both call legs before releasing local switching. 

7.2.3.2 Internnediate Node/GMSC server actions 

When an intermediate node or a GMSC server determines that local switching should be disconnected it shall send the 
LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" to 
the preceding and to the succeeding node. 

The intermediate node or the GMSC Server not initiating the LCLS break shall forward the received LCLS Status 
Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation". 

On receipt of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE set to "LCLS- 
Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request was accepted from the 
preceding (or succeeding) node, the intermediate node or the GMSC Server not initiating the LCLS break shall forward 
message to the succeeding (or preceding) node. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the intermediate node or the GMSC Server not initiating the LCLS break shall forward the message to the 
succeeding (or preceding) node. 

- the intermediate node or the GMSC Server initiating the LCLS break shall not forward the message. 

7.2.3.3 MSC server actions 

When the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS-Disconnection- 
Preparation" is received from the succeeding (or preceding) node, the MSC Server shall send to the BSS the LCLS- 
Connect-Control message with the LCLS -Connection-Status-Control IE set to "Release LCLS". 

If the LCLS-Connect-Control Acknowledge message with the LCLS-BSS-Status IE not indicating LCLS disconnection 
is received, the MSC server shall send to the preceding (or succeeding) node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and a Result code 
IE indicating LCLS Status Change Request accepted. 
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At reception of the LCLS -Notification message with the LCLS-BSS -Status IE set to "Locally switched call is no longer 
locally switched", the MSC server shall send to the succeeding (or preceding) node the LCLS Status Update message 
with the LCLS-Status IE set to "LCLS Not Connected". 

At reception of the LCLS-Connect-Control Acknowledge message with the LCLS-BSS-Status IE set to "Locally 
switched call is no longer locally switched", after sending the LCLS Status Change Request Acknowledge message, the 
MSC server shall send to the succeeding (or preceding) node the LCLS Status Update message with the LCLS-Status IE 
set to "LCLS Not Connected". 

7.2.3.4 BSS actions 

The BSS shall perform the same actions as described in sub-clause 7.2.1.4. 



7.2.4 LCLS Break Example Call Flows 



7.2.4.1 



LCLS Break Connection Model for LCLS 



Figure 7.2.4.1.1 shows the network model for a LCLS break of the mobile call. The "squared" line represents the call 
control signalling. The "dotted/full" line represents the bearer terminations in the MGW. Bearer termination Tl and T6 
are used for the bearer towards BSC and bearer termination T2, T3, T4 and T5 are used for the bearer towards 
preceding/succeeding MGW. 



Control plane link which transmits signalling 

User plane link path through CN 

User plane link which transmits real user plane data 



tUE 



oUE 




Connection Model 1 : Before LCLS Break 



tUE 



oUE 




Connection Model 2: After LCLS Break 
Figure 7.2.4.1.1 : LCLS Break (Network model) 
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7.2.4.2 MSC server Initiated 

Figure 7.2.4.2.1 shows the message sequence example for the MSC server initiated LCLS Break. 



8. LC 

(LCLS 



9a. LCLS 
(LCLS-BSS-S 
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LCLS") 



ACK 

switched call 

switched'") 



11 



2. LCLS StatLJs 
Status-Chang|e 
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Status Chan^' 
LCLS-I 
Code 



10. LCLS Status 
Status = "LCLS 



LCLS Status 
Status = "LCLS 
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Change Recjuest 
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7. LCLS Status Change Re( uest Acknowledge 
Status-Chance = "LCLS-Disconnection-Prepar<ption' 
Code="Statuj Change Reg f \ccepted 



ijlpdate [LCLS- 
connectecT ] 



not 



Update [LCLS- 
npt connected"] 



LCLS Status Update is not sent to 
the preceding MSC server since the 

same information is already 

received from the preceding MSC 

server. 



3. LCLS Status Cljange 
Status-Change = 
Preparation"] 



Acknowledge [LCLS- 

p|reparation", Result 

le Req Accepted"] 




tMSC-S tMGW 



Request 
LCLS-Disconr 



4. LCLS_COIilNECT_CONtROL 
(LCLS-Conne ction-Status-Qontrol = 
"Release LCL S") 



5. LCLS_COrklNECT_CONtROL_ACK 
(LCLS-BSS-4tatus = "call is| I 
switched") 



[LCLS- 
i", Result 



9b. LCLS_ 
BSS-Status 
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M 



locally 



tBSS 



[LCLS- 
ection- 



NQTIFICATION 
locally switched 
switched") 



12. LCLS Status Update [LCLS- 
Status = "LCL S not connectBd"] 



tUE 



locally 



LCLS- 
call is 



Figure 7.2.4.2.1 : MSC Server initiated LCLS break 

1 . The oMSC server determines that local switching should be disconnected. 

2. The oMSC server sends to the succeeding node the LCLS Status Change Request message with the LCLS- 
Status-Change IE set to "LCLS -Disconnection-Preparation". 

3. The iMSC server transfers the LCLS Status Change Request message to the succeeding node. 

4. The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS-Connection-Status- 
Control IE set to "Release LCLS". 

5. The tBSS confirms the reception of the LCLS release request with the LCLS-Connect-Control Acknowledge 
message but does not change the LCLS-BSS status since LCLS release request is not yet received for the 
associated call leg. 

6. The tMSC server sends to the preceding node the LCLS Status Change Request Acknowledge message with 
the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS 
Status Change Request accepted. 

7. The iMSC server transfers the LCLS Status Change Request Acknowledge message to the preceding node. 
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10. 



The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "Release LCLS". 

The BSS reports the LCLS disconnection by sending: 

a) The LCLS-Connect-Control Acknowledge message with the LCLS -BSS -Status IE set to "Locally 
switched call is no longer locally switched" to the oMSC server. 

b) The LCLS -Notification message with the LCLS -BSS -Status IE set to "Locally switched call is no longer 
locally switched" to the tMSC server. 

The oMSC server sends the LCLS Status Update Request message with the LCLS-Status IE set to "LCLS 
Not Connected" to the succeeding node. 



IL The iMSC server transfers the LCLS Status Update message to the succeeding node. 

12. On the receipt of the LCLS -Notification message with the LCLS -BSS -Status indicating LCLS disconnection 
the tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the preceding node. 

NOTE: The iMSC server does not forward the LCLS Status Update message since the same LCLS Status 
is already received from the oMSC server. 

7.2.4.3 BSS Initiated, Immediate LCLS Break 

Figure 7.2.4.3.1 shows the message sequence example for the BSS initiated LCLS Break. 




1. Locally switched 
call is no longer 
locally switched 



2b. LCLS. 
BSS-Statis 
is no 



"locally 
longer localli^ 



NOTIFICATION (LCLS- 

witched call 

switched") 



36. ici o 




2a. LCLS_NOtlFICATION 
Status = "locally 

longer locall^ 



1 . Locally switched 
call is no longer 
locally switched 



(LCLS-BSS- 

switch|ed call is no 

switched") 



LCLS Status Update is not sent to 
the succeeding MSC server since 
the same info is already received 
from the succeeding MSC server. 



1. 



Figure 7.2.4.3.1 : BSS initiated, immediate LCLS break 

The BSS determines that local switching should be disconnected. 



2a, b. The BSS reports the LCLS disconnection by sending the LCLS -Notification message with the LCLS-BSS- 
Status IE set to "Locally switched call is no longer locally switched" to the tMSC server and oMSC server. 

3. a) The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the preceding node. 

b) The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the succeeding node. 

4a. The iMSC server transfers the LCLS Status Update message to the oMSC server. 
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NOTE: At reception of the LCLS Status Update message from the oMSC server, the iMSC server does not 
forward the LCLS Status Update message since the same LCLS Status is already received from the 
tMSC server. 

7.2.4.4 BSS Initiated, LCLS Break requested from Core Network 

Figure 7.2.4.4.1 shows the message sequence example for the BSS initiated but when the LCLS Break is requested from 
the Core Network. 



5b. iq 
(LCLS-i 
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Connection-Stcitus 
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2a. LCLS 
(LCLS-Break 



N(t)TIFICATION 
Request) 



4a. LCLS Status Che 
Change = "LCLS 
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Acknowledge [LCL 
"LCLS-Di sconnection-Pijeparati 
Codef"Status Change 



Acknowledg 
ction 
^ode="Statu^ Change Reg |^ ccepted"] 



Status-Change 
(Change Req A 



[LCLS-Status 
connected"] 




LS- 



Change Request 

Status-Change = 

ion", Result 

Req Accepted"] 



sl3hange Request 
e = "LCLS-Disconnection-Prepar«btion' 



"LCLS- 
:cepted"] 



LCLS Status Update message is not 
forwarded since the same 
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the preceding MSC server. 
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Figure 7.2.4.4.1 : BSS initiated, LCLS Release ordered from Core Network 

1. The BSS determines that local switching should be disconnected. 

2a, b. The BSS requests the LCLS disconnection by sending the LCLS -Notification message with LCLS-Break- 
Request IE set to "LCLS Break Request" to the oMSC server and tMSC server. 

3. a) The oMSC server sends to the succeeding node the LCLS Status Change Request message with the 
LCLS -Status-Change IE set to "LCLS-Disconnection-Preparation". 

b) The tMSC server sends to the preceding node the LCLS Status Change Request message with the LCLS- 
Status-Change IE set to "LCLS-Disconnection-Preparation". 

4a, b. The iMSC server transfers the LCLS Status Change Request message to the succeeding/preceding node. 

5. a) The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 
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b) The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

6. a) The tBSS confirms the reception of the LCLS release request with the LCLS-Connect-Control 
Acknowledge message but does not change the LCLS-BSS status since LCLS release request is not yet 
received for the associated call leg. 

b) The oBSS reports the LCLS disconnection by sending the LCLS-Connect-Control Acknowledge message 
with the LCLS-BSS -Status IE set to "Locally switched call is no longer locally switched" to the oMSC 
server. 

c) The tBSS reports the LCLS disconnection by sending the LCLS -Notification message to the tMSC 
server. 

7. a) On the receipt of the LCLS-Connect-Control Acknowledge message with the LCLS-BSS status still 
indicating local switching the tMSC server sends to the preceding node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the 
Result code IE set to LCLS Status Change Request accepted. 

b) On the receipt of the LCLS-Connect-Control Acknowledge message the oMSC server sends to the 
succeeding node the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS Status Change Request 
accepted. 

8. a) The iMSC server transfers the LCLS Status Change Request Acknowledge message to the preceding 
node. 

b) The iMSC server transfers the LCLS Status Change Request Acknowledge message to the succeeding 
node. 

NOTEl : The oMSC server already requested the LCLS break from the oBSS (step 5b) and due to that it 
does not perform any action on the receipt of the LCLS Status Change Request Acknowledge 
message. The tMSC server does not perform any action on the receipt of the LCLS Status Change 
Request Acknowledge message since it already requested the LCLS break from the tBSS (step 5a) 
and already received LCLS -Notification message indicating LCLS disconnection (step 6c). 

9. At reception of the LCLS-Connect-Control Acknowledge message indicating LCLS disconnection the oMSC 
server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" to the 
succeeding node. 

10. The iMSC server transfers the LCLS Status Update message to the succeeding node. 

11. On the receipt of the LCLS -Notification message indicating LCLS disconnection the tMSC server sends the 
LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" to the preceding node. 

N0TE2: At reception of the LCLS Status Update message from the tMSC server, the iMSC server does not 
forward the LCLS Status Update message since the same LCLS Status is already received from the 
oMSC server. 

7.2.4.5 Intermediate Node/GMSC Server Initiated 

Figure 7.2.4.5.1 shows the message sequence example for the network initiated LCLS Break. 
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Figure 7.2.4.5.1 : Intermediate Node / GMSC Server initiated LCLS break 

1 . The iMSC server determines that local switching should be disconnected. 

2a, b. The iMSC server send the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" to the preceding node and to the succeeding node. 

3. a) The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

b) The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

4. a) The oBSS confirms the reception of the LCLS release request but does not change the LCLS-BSS status 
since LCLS release request is not yet received for the associated call leg. 

b) The tBSS reports the LCLS disconnection by sending the LCLS-Connect-Control Acknowledge message 
with the LCLS -BSS-Status IE set to "Locally switched call is no longer locally switched" to the tMSC server. 

c) The oBSS reports the LCLS disconnection by sending the LCLS -Notification message to the oMSC 
server. 

5. a) On the receipt of the LCLS-Connect-Control Acknowledge message with the LCLS-BSS status still 
indicating local switching the oMSC server sends to the succeeding node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the 
Result code IE set to LCLS Status Change Request accepted. 

b) On the receipt of the LCLS-Connect-Control Acknowledge message the tMSC server sends to the 
preceding node the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS Status Change Request 
accepted. 
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NOTEl : Since the LCLS disconnection is ordered by the iMSC server it does not forward the LCLS Status 
Change Request Acknowledge message to the succeeding node. 

6. a) At reception of the LCLS-Connect-Control Acknowledge message indicating LCLS disconnection the 
tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" 
to the preceding node. 

b) On the receipt of the LCLS -Notification message the oMSC server sends the LCLS Status Update 
message with the LCLS-Status IE set to "LCLS Not Connected" to the succeeding node. 

N0TE2: Since the LCLS disconnection is ordered by the iMSC server it does not forward the LCLS Status 
Update message to the preceding/succeeding node. 

7.2.4.6 MSC server Initiated when Access Side Termination is isolated in MGW 

Figure 7.2.4.6.1 shows the message sequence example for the MSC server initiated LCLS Break for the case when the 
LCLS negotiation through the Core Network enabled the MSC server to use the option to isolate access side termination 
from the network side termination. 

In this example the oMSC server moves the originating UE (access side termination Tl) back to the context oC with 
network side termination T2 and requests the oMGW to be bothway through-connected after the oMSC server 
determined that local switching should be disconnected and sent to the succeeding node the LCLS Status Change 
Request message indicating LCLS disconnection preparation. 




2b. MO^/ request (Tl) / MOV reply 



2a. LCLS Sta(us 

[LCLS-Status- 

Disconnectior 



Change Request: APM 
Change = "LCLS- 
Preparation"] 



Context oC 

Join Bearer "dermination 



For succeeding signaling sequences see figure 7.2.4.2.1 steps 3 - 12 



Figure 7.2.4.6.1 : MSC initiated LCLS break, access side termination isolated in MGW 

1 . The oMSC server determines that local switching should be disconnected. 

2. The oMSC server sends to: 

a) the succeeding node the LCLS Status Change Request message with the LCLS -Status-Change IE set to 
"LCLS -Disconnection-Preparation"; 

b) the oMGW request to move the access side termination Tl to context oC with the network side 
termination T2; 

NOTE 1 : Steps 2a and 2b can be performed in parallel. 

NOTE 2: If the MSC server has previously used the Change Through-Connection procedure and requested 
the MGW to change the through-connection of the bearer to inactive instead of using the Isolate 
Bearer termination procedure then the MSC server will use the Change Through-Connection 
procedure to request the MGW to change the through-connection of the bearer to be both- way 
through-connected. 

3. The further steps are performed as defined in sub-clause 7.2.4.2, steps 3-12. 
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7.3 LCLS Re-establishment 
7.3.1 MSC server Initiated 

7.3.1.1 Principles 

The following Re-establishment procedures describe the scenario when a node has requested an LCLS -break for a 
temporary period while applying a supplementary service or CN intervention and once completed wishes to resume the 
LCLS connection. If the node which broke the LCLS does not re-establish the LCLS via these procedures, LCLS can 
also be re-established by another interaction such as handovers (as specified in clause 8) or subsequent LCLS 
negotiations (e.g. due to supplementary service interaction). If a node in the path does not accept the LCLS Status 
Change Request (e.g. re-establishment) it shall respond with a LCLS Status Change Request Acknowledge message 
containing a Result Code IE set to "Status Change Request rejected", and not forward the LCLS Status Change Request 
to the succeeding (or preceding) node. 

7.3.1 .2 MSC server actions 

7.3.1 .2.1 LCLS re-establishment to the network side 

The MSC server which initiates LCLS re-establishment shall send the LCLS Status Change Request message with the 
LCLS -Status-Change IE to the succeeding (or preceding) node to requests a change in LCLS Status in the CN. 

Once the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS -Connection- 
Preparation" is received from the preceding (or succeeding) node, the MSC server shall check if the requested LCLS 
Status is allowed and shall send the LCLS Status Change Request Acknowledge message with the correct LCLS -Status- 
Change IE value and with a Result code back to the preceding (or succeeding) node. The Result code indicates whether 
LCLS Status Change Request is accepted or not. 

7.3.1 .2.2 LCLS re-establishment to the BSS 

Once the LCLS -Status-Change Request message with LCLS -Status-Change IE or the LCLS -Status-Change Request 
Acknowledge message with the LCLS-Status-Change IE sent from the preceding (or succeeding) node is received, the 
MSC sever shall check if the requested LCLS Status is allowed or not and if it is allowed then the MSC Server shall 
send the LCLS-CONNECT-CONTROL message with LCLS-Connection-Status-Control set to "connect" to the BSS 

7.3.1 .2.3 LCLS Status update to the network side 

Once the LCLS -Notification message or LCLS-Connect-Control-ACK message sent from BSS is received by MSC 
server, and if the received LCLS -BSS -Status indicates local switching, the MSC server shall send to the succeeding (or 
preceding) node the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" if the same LCLS 
status update is not already received from the succeeding (or preceding) node.. 

7.3.1 .3 GMSC server actions 

Once the LCLS Status Change Request message with the LCLS-Status-Change IE sent from preceding (or succeeding) 
node is received, the GMSC sever shall check if the requested LCLS Status is allowed or not and if it is allowed the 
GMSC server shall forward the LCLS Status Change Request message with correct value to the succeeding (or 
preceding) node. 

At the reception of the LCLS-Status-Change Request Acknowledge message from the succeeding/preceding node the 
GMSC server shall forward the received message to the preceding/succeeding node. 

Once the LCLS -Status-Update message with the LCLS Status IE sent from preceding/succeeding node is received by 
GMSC server, 

- the GMSC Server shall forward the message to the succeeding/preceding node if the same request is not already 
received from the succeeding/preceding node. 

- the GMSC Server shall not forward the message if the same request is already received from the 
succeeding/preceding node. 
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7.3.1.4 BSS actions 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "connect LCLS" 
the BSS may estabUsh LCLS (following the principles described in sub-clause 4.4) and notify the CN as described for 
LCLS call establishment. 

7.3.2 BSS Initiated 

BSS Initiated LCLS re-establishment is not supported for LCLS. 

7.3.3 Intermediate Node / GMSC Server Initiated 

7.3.3.1 Principles 

The following Re-establishment procedures describe the scenario when a node has requested an LCLS -break for a 
temporary period while applying a supplementary service or CN intervention and once completed wishes to resume the 
LCLS connection. If the node which broke the LCLS does not re-establish the LCLS via these procedures, LCLS can 
also be re-established by another interaction such as handovers (as specified in clause 8) or subsequent LCLS 
negotiations (e.g. due to supplementary service interaction). If a node in the path does not accept the LCLS Status 
Change Request (e.g. re-establishment) it shall respond with a LCLS Status Change Request Acknowledge message 
containing a Result Code IE set to "Status Change Request rejected", and not forward the LCLS Status Change Request 
to succeeding/preceding node. 

7.3.3.2 Intermediate Node / GMSC server actions 

When an intermediate node or the GMSC server determines that local switching should be re-established it shall send 
the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS -Connection-Preparation" to 
the preceding and to the succeeding node. 

The intermediate node or the GMSC Server not initiating the LCLS re-establishment shall check if the requested LCLS 
Status is allowed or not and if it is allowed the intermediate node shall forward the received LCLS Status Change 
Request message. 

On receipt of the LCLS Status Change Request Acknowledge message with the LCLS -Status-Change IE set to "LCLS 
Connection Preparation" and a Result code IE from the preceding/succeeding node, the intermediate node or the GMSC 
Server not initiating the LCLS re-establishment shall forward message to the succeeding/preceding node. The Result 
code indicates whether LCLS Status Change Request is accepted or not. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" from the 
preceding/succeeding node: 

- the intermediate node or the GMSC Server not initiating the LCLS re-establishment shall forward the message to 
the succeeding/preceding node. 

- the intermediate node or the GMSC Server initiating the LCLS re-establishment shall not forward the message. 

7.3.3.3 MSC server actions 

When the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS Connection 
Preparation" is received from the succeeding (or preceding) node, the MSC Server shall check if the requested LCLS 
status is allowed or not and if it is allowed then the MSC Server shall send to BSS the LCLS-Connect-Control message 
with the LCLS -Connection-Status-Control IE set to "connect". The MSC server shall send LCLS Status Change 
Request Acknowledge message with the correct LCLS -Status-Change IE value and a Result code back to the preceding 
(or succeeding) node. The Result code indicates whether LCLS Status Change Request is accepted or not. 

At reception of the LCLS-Connect-Control Acknowledge message or the LCLS -Notification message with the LCLS- 
BSS-Status IE set to "Call is Locally switched", the MSC server shall send to the succeeding (or preceding) node the 
LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" if the same LCLS status update is not 
already received from the succeeding (or preceding) node. 
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7.3.3.4 BSS actions 

The BSS shall perform the same actions as described in sub-clause 7.3.1.4. 

7.3.4 LCLS Re-establishment Example Call Flows 



7.3.4.1 



LCLS Re-establishment Connection Model for LCLS 



Figure 7.3.4.1.1 shows the network model for a LCLS Re-establishment of the mobile call. The "squared" line 
represents the call control signalling. The "dotted/full" line represents the bearer terminations in the MGW. Bearer 
termination Tl and T6 are used for the bearer towards BSC and bearer termination T2, T3, T4 and T5 are used for the 
bearer towards preceding/succeeding MGW. 



Control plane link which transmits signalling 

User plane link path through ON 

User plane link which transmits real user plane data 



tUE 



oUE 




tUE 



oUE 



7.3.4.2 



Connection Model 1 : Before LCLS Re-establishment 




Connection Model 2: After LCLS Re-establishment 
Figure 7.3.4.1.1: LCLS Re-establishment (Network model) 

MSC server Initiated Example Call Flow 



Figure 7.3.4.2.1 shows the message sequence example for the MSC server initiated LCLS Re-estabHshment. In the 
example the MSC server trigger the LCLS negotiation in the CN. The BSS establishes local switching when both legs 
are informed LCLS is allowed. 
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Figure 7.3.4.2.1 : MSC server Initiated LCLS Re-establishment 

The oMSC server determines that local switching should be re-established. The oMSC server sends to the 
succeeding node the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS- 
Connection-Preparation" . 

The iMSC server transfers the LCLS Status Change Request message to the tMSC server. 

The tMSC server sends LCLS Status Change Request Acknowledge message to the preceding node. 

The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "connect". 



NOTE: Step 3 and 4 can be performed paralleled. 

5. The iMSC server transfers the LCLS Status Change Request Acknowledge message to the oMSC server. 

6. The oBSS confirms the reception of the LCLS connect request but does not change the LCLS -ESS status 
since LCLS connect request is not yet received for the associated call leg. 

7. On receipt of LCLS Status Change Request Acknowledge message, the oMSC server sends to the oBSS the 
LCLS-Connect-Control message with the LCLS -Connection-Status-Control IE set to "connect". 
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10. 
11. 



Because LCLS connect requests are received for the associated call leg, the oBSS/tBSS re-establish the 
LCLS. 

The oBSS reports the LCLS connection by sending the LCLS-Connect-Control Acknowledge message to the 
oMSC server. 

The tBSS reports the LCLS connection by sending the LCLS -Notification message to the tMSC server. 

The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the succeeding node. 



12. The iMSC server transfers the LCLS Status Update message to the tMSC server. 

13. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. The iMSC server does not forward the LCLS Status Update message to the oMSC 
server since the same LCLS Status is already received from the oMSC server. 



7.3.4.3 



Intermediate Node / GMSC Server Initiated Example Call Flow 



Figure 7.3.4.3.1 shows the message sequence example for the Intermediate Node / GMSC Server initiated LCLS Re- 
establishment. 
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Figure 7.3.4.3.1 : Intermediate Node / GMSC Server Initiated LCLS Re-establishment 

1 . The iMSC server determines that local switching should be established. 
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2. The iMSC server sends the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Connection-Preparation" to the oMSC server. 

3. The iMSC server sends the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS-Connection-Preparation" to the tMSC server. 

4. The oMSC server sends LCLS Status Change Request Acknowledge message to the succeeding node. 

5. The tMSC server sends LCLS Status Change Request Acknowledge message to the preceding node. 

6. The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "connect". 

7. The oBSS confirms the reception of the LCLS connect request but does not change the LCLS-BSS status 
since LCLS connect request is not yet received for the associated call leg. 

8. The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS-Connection-Status- 
Control IE set to "connect". 

9a. The tBSS reports the LCLS connection by sending the LCLS-Connect-Control Acknowledge message to the 
tMSC server. 

9b. The oBSS reports the LCLS connection by sending the LCLS -Notification message to the oMSC server. 

10. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. 

n. The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the succeeding node. 

NOTE: Since LCLS re-establishment is ordered by the iMSC server it does not forward the LCLS Status Update 
message to the preceding/succeeding node. 

7.3.4.4 MSC server Initiated when Access Side Termination is isolated in MGW 

Figure 7.3.4.4.1 shows the message sequence example for the MSC server initiated LCLS Re-establishment for the case 
when the LCLS negotiation through the Core Network enabled the MSC server to use the option to isolate access side 
termination from the network side termination. 

In this example the oMSC server requests the oMGW to interrupt the communication on the bearer by using the Isolate 
Bearer Termination Procedure (i.e. to isolate access side termination Tl from the network side termination T2) after the 
oBSS re-established local switching. 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 



65 



ETSI TS 123 284 VI 0.1.0 (2011-06) 



oUE 




oBSS 




oMSC-S 




iMSC-S 




tMSC-S 




tBSS 




tUE 




























































oMGW 








iMGW 






tMGW 










































For preceding signaling sequences see figure 7.3.4.2.1 steps 1- 10 
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Figure 7.3.4.4.1 : MSC server Initiated LCLS Re-establishment, access side termination isolated in 

MGW 

1-10. When the oMSC server determines that local switching should be re-established it initiates the LCLS Re- 
estabUshment procedure specified in sub-clause 7.3.4.2, steps 1 - 10. 

11. a) The oMSC server send to the oMGW request to isolate the access side termination Tl from the network 
side termination T2. 

NOTE 1 : The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

b) The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS 
Connected" to the succeeding node. 

NOTE 2: Steps 11a and 1 lb can be performed in parallel. 

12. The iMSC server transfers the LCLS Status Update message to the tMSC server. 

13. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. The iMSC server does not forward the LCLS Status Update message to the oMSC 
server since the same LCLS Status is already received from the oMSC server. 



8 



Handover/Relocation 



8.1 



UMTS to UMTS 



For Inter-MSC Handover UMTS to UMTS the Anchor MSC server shall include the GCR and the LCLS -Negotiation 
IE in lAM to the Target MSC server. The Target MSC server shall then perform LCLS Negotiation as defined in clause 
4.2 and include the LCLS -Negotiation response in the APM or ACM or CFG. The Target MSC server may then use the 
LCLS parameters to enable LCLS if a subsequent UTRAN to GERAN handover occurs. 
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8.2 UMTS to GSM 

8.2.1 General 

The procedures specified in 3GPP TS 23.205 [2] for BICC based CS Core Network and 3GPP 23.231 [3] for SIP-I 
based CS Core Network shall be followed. The following clauses describe the additional requirements for LCLS 
functionality. 

8.2.2 Intra-MSC UMTS to GSM Handover 

8.2.2.1 Intra-MSC UMTS to GSM Handover that establishes Local Switching 

8.2.2.1.1 General 

When LCLS is not established for a call and an intra-MSC UMTS to GSM handover occurs that makes the call local, 
the call can be locally switched in the Target BSS. The following clauses describe the additional requirements for intra- 
MSC UMTS to GSM handover that establish LCLS. 

8.2.2.1 .2 Relocation Required 

When the MSC server receives the Relocation Required message from the serving RNC, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. 

The MSC server sends the Handover Request message to the Target BSS as for the normal case but shall include the 
GCR IE, the LCLS -Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 

8.2.2.1 .3 Handover Request Acknowledge 

If the Target BSS supports LCLS feature then it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the MSC Server that the BSS supports the LCLS feature. 

8.2.2.1 .4 Handover Complete 

The target BSS sends Handover Complete including the LCLS-BSS-Status, which indicates to the MSC server that the 
call is locally switched. 

NOTE: The target BSS will send LCLS -Notification message to the MSC at the other call leg indicating the call 
is locally switched. 

8.2.2.1.5 Example 

8.2.2.1 .5.1 Connection Model 

Figure 8.2.2.1.5.1.1 shows the network model for the Basic Intra-MSC UMTS to GSM handover when LCLS is 
established as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards RNC, bearer termination Ta is used for the bearer towards the 
succeeding/preceding MGW, that is MGW-2 and bearer termination Tt is used towards the Target BSS. In MGW-2 the 
bearer termination T2 is used for the bearer towards BSS-2 and bearer termination Ti is used for the bearer towards 
MGW-1. 

In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 
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Connection Model 2: During Handover, Tt is isolated from Ts, Ta is one-way connected to Ty 
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Connection Model 3: After Handover, LCLS is established and both call legs are in Target BSS 

(=BSS-2) 

Figure 8.2.2.1.5.1.1 : Basic Intra-MSC UMTS to GSM Handover (network model) 
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8.2.2.1.5.2 



Basic Sequence for Intra-MSC UMTS to GSM Handover that establishes Local 
Switching 
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Figure 8.2.2.1.5.2.1 : Intra-MSC UMTS to GSM Handover that establishes Local Switching 

1 . lu Relocation Required message is received from the RNC requesting an intra-MSC UMTS to GSM 
handover. The call is currently not locally switched. 

2. The MSC-1 server requests the MGW-1 to reserve circuit or Connection Point towards the Target-BSS 

3. The MSC-1 server sends the Handover Request message to the Target BSS with the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

4. Target BSS performs call leg correlation with GCR to determine if another call leg is active with the same 
GCR. The Target BSS reports in Handover Request Acknowledge message that the local call was found but 
LCLS is not yet established. 

5. The MSC-1 server triggers the Relocation Command message. 

6. The UE-1 is detected at the target BSS. Then the Target BSS/BSS-2 can internally transmit the user plane 
data. 

7. In the Handover Complete message the Target-BSS indicates to the MSC-1 server in the LCLS-BSS-Status 
IE that the call has been locally switched. 

8. The MSC-1 server requests the old serving RNC to release the old call leg. 
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9. The Serving BSS-2 informs the MSC-2 server that the call has been locally switched via LCLS_Notification 
message. 

10. Releasing of the old call leg to the RNC is completed. 

1 1 . The termination Ts to the old RNC is removed from the Access MGW-1 . 

12. The MSC-1 server informs succeeding CN nodes that LCLS is connected. 

NOTE : When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

8.2.2.2 Intra-MSC UMTS to GSM Handover that does not establish LCLS 

Intra-MSC UMTS to GSM Handover that does not estabHsh LCLS follows the procedures in 8.2.2.1. The differences 
are: 

- in the step 7, the Target BSS informs MSC-1 server that the call is not locally switched in the Handover 
Complete message. 

- step 9 and step 12 are not triggered. 

8.2.3 Inter-MSC UMTS to GSM Handover 

8.2.3.1 Inter-MSC UMTS to GSM Handover that establishes Local Switching 

8.2.3.1.1 General 

When LCLS is not established for a call and an inter-MSC UMTS to GSM handover occurs that makes the call local, 
the call can be locally switched in the Target BSS. The following clauses describe the additional requirements for inter- 
MSC handovers that estabHsh LCLS. 

8.2.3.1.2 MSG-1 /MGW-1 

8.2.3.1.2.1 Relocation Required 

When MSC-1 Server receives the Relocation Required message from the serving RNC and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call and LCLS negotiation IE to the Target MSC 
Server in a MAP Prepare-Handover_Request message. 

8.2.3.1 .2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS -BSS -Status IE the Anchor MSC-1 Server configures the bearer terminations in MGW-1 and 
sends the GCR and LCLS -Negotiation information to the target MSC-Server. 

8.2.3.1 .2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.2.3.1 .2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target MGW (T2) from 
the termination to the RNC(Ts) and configures the Anchor termination (Ti) one-way DL towards the Target MGW 
termination (T2). Termination to the RNC (Ts) is both- way connected to Anchor termination (Ti) since it is also 
receiving UL user data from termination to the RNC (Ts). 
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8.2.3.1 .2.5 Relocation Command/Handover Detect 

The MSC-1 Server uses the Change Flow Direction procedure to requests the MGW-1 to set the Handover Device to 
intermediate state. 

8.2.3.1 .2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the related lu-interface connection 
towards RNC. The MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the 
bearer termination towards the RNC. 

The MSC-1 server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating that LCLS is established. 

8.2.3.1 .3 Target MSC Server / Target MGW 

8.2.3.1 .3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives MAP Prepare Handover Request message. The 
Target MSC server sends the Handover Request message to the Target BSS as for the normal case but shall include the 
GCR IE, the LCLS -Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 

8.2.3.1 .3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.2.3.1 .3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.2.3.1 .3.4 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 

8.2.3.1 .3.5 Handover Complete 

When LCLS has been established during the handover procedure, the target BSS informs the target MSC-Server that 
the call has been locally switched in the Handover Complete message. 

NOTE: The target BSS will send LCLS -Notification message to the MSC at the other call leg indicating the call 
is locally switched. 

8.2.3.1 .4 Example of Inter-MSG UMTS to GSM Handover that establishes Local Switching 

8.2.3.1 .4.1 Connection Model 

Figure 8.2.3.1.4.1.1 shows the network model for the Basic Inter-MSC UMTS to GSM handover when LCLS is 
established as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards RNC, bearer termination Ti is used for the bearer towards the 
succeeding/preceding MGW, that is MGW-2 and bearer termination Tj is used towards the Target MGW. In MGW-2 
the bearer termination T4 is used for the bearer towards BSS-2 and bearer termination T3 is used for the bearer towards 
MGW-1. In Target-MGW the bearer termination Tt is used towards the Target-BSS and bearer termination T5 is used 
towards MGW-1. 
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In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 

User plane link which transmits real user plane data within BSS and to UE 
User plane link which transmits real user plane data through the CN and to UE 
User plane link path through CN, connected 
Control plane link which transmits signalling 
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Connection Model 2: During Handover, T2 is isolated from Ts, Ti is one-way connected to T2 
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Connection Model 3: After Handover, LCLS is established and both call legs are in Target BSS 
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8.2.3.1.4.2 



Figure 8.2.3.1.4.1.1 : Basic Inter-MSC UMTS to GSM Handover (network model) 



Basic Sequence 



Figures 8.2.3.1.4.2.1 and 8.2.3.1.4.2.2 show the message sequence example for the Basic Inter-MSC UMTS to GSM 
Handover shown in the corresponding network model Figure 8.2.3.1.4.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-1 server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.2.3.1.4.2.1 : Initial phase of Inter-MSC UMTS to GSM Handover establishing Local Switching 

1. lu Relocation Required Request is received from RNC requesting an inter-MSC handover. The call is 
currently not locally switched. 

2. The MSC-1 server determines that inter-MSC handover is required and sends the MAP Prepare-Handover 
Request message to target MSC-Server which includes LCLS Negotiation and GCR. 

3a, b. The Target-MSC-Server requests the target MGW to reserve circuit or Connection Point towards the Target- 
BSS 

4. The Target MSC-Server sends Handover Request message to the Target BSS with GCR, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

5. Target BSS performs call leg correlation with GCR to find if another call leg is active with same GCR. The 
BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not yet 
established. 

6a, b. (These signalling steps are only applicable to AoIP.) When the Target MSC-Server receives the BSSMAP 

Handover Request- Ack message, it sends the BSC-B IP address and UDP Port number to the MGW-B using 
the Configure RTP Connection Point procedure. 
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7. The Target MSC-Server sends the MAP Prepare Handover Response message to MSC-1 server. 

8a, b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 
Target MGW (T2) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ti) one-way DL towards the Target MGW termination (T2). 

9. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 1: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 2: The LCLS-Negotiation IE in step 9 can be different from LCLS Negotiation IE in step 2, because 
step 9 is BICC signalling and the IE value can be changed by intermediate MSC-Servers. 

10a, b. Target MSC-Server reserves bearer connection T5 towards MGW-1. 

11. After Target MGW has replied with the bearer address and the binding reference (Step 10b), the Target 
MSC-Server returns APM with selected codec plus LCLS-Negotiation IE. 

12. Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing of 
the UE-1 on the radio path when the ACM is sent and MSC-1 server initiates the handover execution when 
receiving ACM. 
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Figure 8.2.3.1.4.2.2: Completion phase of Inter-IVISC UMTS to GSM l-landover establisliing Local 

Switching 

13-18. When the local switching has been established during the handover procedure, the target BSS shall inform 
the target MSC-Server that the call has been locally switched in HANDOVER COMPLETE, and the target 
BSS shall also send a new message LCLS -Notification with LCLS-BSS-Status IE to inform the MSC-2 
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server that the local switching has been established. In steps 16a and 16b the MSC-1 server configures 
MGW-1 for the completion of the handover. 

19. A-HO-DETECT/COMPLETE when received is included in the MAP-Send-End-Signal request and send 
back to the MSC-1 server. 

20. Target MSC-Server sends ANSWER when A-HO-DETECT/COMPLETE is received. 
21a, b. MSC-1 Server releases the call leg in RNC. 

22a, b. MSC-1 server releases the bearer termination towards RNC. 

23. Target MSC-Server informs the MSC-1 server about the LCLS Status. 

24. MSC-1 server (Anchor MSC-Server) sends LCLS -Status-Update message to the far end MSC-2 server. 

NOTE 3: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

25. Local switching is established in the BSS. 

8.2.3.2 Inter-MSC UMTS to GSM Handover that does not establish Local Switching 

Inter-MSC UMTS to GSM Handover that does not establish Local Switching follows the procedures in 8.2.3.1. The 
differences are: 

- in the step 17, the target BSS informs target MSC that the call is not locally switched in the Handover Complete. 

- step 18, step 23, step 24 and step 25 are not triggered. 

8.3 GSM to UMTS 

8.3.1 Intra-MSC GSM to UMTS Relocation 

8.3.1.1 General 

When a call is locally switched through the BSS and an intra-MSC GSM to UMTS handover occurs, the LCLS shall be 
broken and the user plane shall be connected via the core network. The Intra-MSC GSM to UMTS relocation procedure 
specified in 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The following clauses describe the 
additional requirements for intra-MSC GSM to UMTS handovers of LCLS related calls. 

To this end the BSS which is in local switch which is serving the user equipment which is not moving to the RNC 
bicasts user data UL to the core network so that immediately the user equipment which is moving is attached to the 
RNC it can receive DL data from the core network. 

During a Locally Switched (intra-BSS) Connection when no bicasting occurs there is no data transmission through the 
core network. In this release the use plane is kept active and therefore does not need to be re-activated when the LCLS 
is broken due to GSM to UMTS handover out of LCLS. 

8.3.1 .2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to provide 
a binding reference and a bearer address using the Prepare Bearer procedure. The MSC server shall use the Change 
Flow Direction procedure to request the MGW to set the Handover Device to the initial state, see sub-clause 8.4.1.1.3. 

8.3.1 .3 lu Relocation Request Acknowledge 

Upon receipt of the Relocation Request Acknowledge message, the MSC Server shall send to the adjacent call node the 
LCLS -Status-Change-Request message to indicate "LCLS Disconnection-Preparation-for handover". 
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If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.3.1 .4 Handover Command/lu Relocation Detect 

When the MSC server sends the Handover Command message or alternatively if it receives the Relocation Detect 
message, if the MSC server followed the MGW control procedures for a non-LCLS call and kept the Termination to the 
Serving BSS connected then it shall use the Change Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state. However if the MSC server isolated Ts and set Tt to bothway through-connected then no 
MGW control procedure is required at this point. 

When the Handover Command message from the CN is received by the BSS, the BSS should start bi-casting the UL 
user plane data to the CN at the other call leg before sending Handover Command message to the MS, if the BSS did 
not receive an explicit indication on the other call leg to start bi-casting. 

8.3.1 .5 lu Relocation Complete 

When the MSC server receives the lu Relocation Complete message, it releases the A-interface line towards the serving 
BSS. The MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination (Ts) towards the serving BSS. 

The MSC server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS is disconnected. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS -Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Complete message received from the serving BSS also means that LCLS is disconnected. 

8.3.1.6 Example 

8.3.1 .6.1 Connection Model 

Figure 8.3.L6.L1 shows the network model for Intra-MSC GSM to UMTS Handover, where the call leg pertinent to the 
UE-1 is handed over from the serving BSS-1 to the Target RNC. BSS-1 is the same as BSS-2 when LCLS is established 
for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. 
Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the 
bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the Target 
RNC. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate LCLS 
specific issues. 
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User plane link which transmits real user plane data within the BSS and to UEs 
User plane link which transmits real user plane data through the CN and to UEs 
User plane path through the CN, connected 
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After Handover 
Ta= Anchor 
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Connection Model 4: LCLS is released in BSS-2, old serving Termination Ts is removed 
Figure 8.3.1.6.1.1 : Network model for Intra-MSC GSM to UMTS Handover that breaks LCLS 

8.3.1 .6.2 Basic Sequence for GSM to UMTS Handover that breaks Local Switching 

Figure 8.3.1.6.2.1 shows the signalHng flow for GSM to UMTS handover that breaks Local Switching. 
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Figure 8.3.1.6.2.1 : Intra-MSC GSM to UMTS Handover that terminates Local Switching 

The Handover Required message is received from BSS-1 requesting an intra-MSC GSM to UMTS handover. 
The call is currently locally switched so the MSC-1 server can know that the GSM to UMTS handover at one 
end will break local switch (the local switch is not broken in the serving BSS (BSS-1) until the UE-1 has 
moved from BSS-1 and the MSC-1 server has sent the Clear Command message to the BSS-1). 

In this example the Anchor MSC-1 server requests from its MGW-1 the seizure of the bearer termination Tt 
towards the Target RNC and through-connects it bothway to Ta. Additionally it isolates the old serving 
Termination Ts. This makes the GSM to UMTS handover more efficient than current non-LCLS GSM to 
UMTS handovers as immediately when the UE-1 is handed over to the target RNC it will be able to send UL 
user data to the UE-2. 

NOTE 1 : This flow shows the termination to the Target RNC as always connected bothway. This is a change 
to the existing call handling which would normally connect the termination as one-way and then 
change to bothway after receiving the lu Relocation Detect message. However the termination 
does not need to be connected one-way and will in fact make the break in speech worse since UL 
data cannot be sent from the UE-1 until the MGW topology is modified, also it saves the 
additional intermediate H.248 modification step. 

Anchor MSC-1 server sends the lu Relocation Request message to the target RNC. 

The target RNC returns the lu Relocation Request Acknowledge message. 
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5. Anchor MSC-1 server shall send the LCLS-Status-Change-Request message to the succeeding MSC server 
asking it to prepare for LCLS disconnection due to handover to trigger the far end MSC-2 server to send the 
LCLS-Connect-Control message to BSS-2. 

NOTE 2: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

5a. The far end MSC-2 server requests the BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.3.1.6.1.1 
Connection Model 2. This triggers the BSS-1 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send any DL data 
it receives directly to the served UE. Since the BSS-1 cannot receive DL data at the same time as it receives 
local data (Ts is isolated) this will minimise the break in user plane data even more than for existing non- 
LCLS handover. 

NOTE 3: The Serving BSS-1 shall forward the user plane data from the UE-1 to the UE-2 while the UE-1 is 
served by the BSS-1. The UL user plane data are bi-cast to both MGW2 and local path by the 
BSS-2. The MGW-2 transmits the user plane data to the MGW-1, and the MGW-1 will transmit 
the user plane data to the target RNC. When the UE-1 leaves the serving BSS-1 and begins 
sending UL data from the Target RNC, that data will then be received via the A-interface leg at the 
serving BSS-2. 

5b. BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

6. Anchor MSC-1 server triggers the Handover Command message. When the UE-1 moves to the Target RNC 
in this example it can immediately send UL data through the CN to the UE-2 and also can receive DL data 
from the UE-2 via the CN since the MGW-1 topology for Ta, Tt is already both way connected. This is a 
change from the current non-LCLS solution but is more efficient since the non-LCLS solution needs to set 
this to one-way DL only until it receives lu Relocation Detect message. 

7. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

8. UE-1 is detected at the target RNC. BSS-l/BSS-2 may continue to send the user plane data locally until the 
Clear Command message is received. 

9. When the MSC-1 Server receives the lu Relocation Complete message MSC-1 Server knows that the call is 
not possible to be locally switched. 

10. MSC-1 server requests the old serving BSS-1 to clear the old call leg. BSS-1 stops sending locally the user 
data from UE-1, LCLS is broken. 

11. Serving BSS-2 informs the MSC-2 server that LCLS is broken via LCLS_Notification message. 

12. Clearing of the old call leg to the Serving BSS-1 is completed. 

13. The termination Ts to the old serving BSS-1 is removed from the Access MGW-1. 

14. Anchor MSC-1 server informs succeeding CN nodes that LCLS is disconnected. 

NOTE 4: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

8.3.2 Inter-MSC GSM to UMTS Relocation 
8.3.2.1 General 

When a call is locally switched through the BSS and an inter-MSC GSM to UMTS handover occurs the LCLS shall be 
broken and the user plane shall be connected through the core network. The Inter-MSC GSM to UMTS handover 
procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The 
following clauses describe the additional requirements for inter-MSC GSM to UMTS handovers of LCLS related calls. 
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8.3.2.2 MSC-1 / MGW-1 

8.3.2.2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call and LCLS negotiation IE to the Target MSC 
Server in a MAP Prepare-Handover_Request message. 

8.3.2.2.2 lu Relocation Request Acknowledge 

Upon receipt of the MAP Prepare-Handover-Response including lu Relocation Ack message, the MSC-1 Server shall 
send to the adjacent call node the LCLS-Status-Change-Request message to indicate "LCLS Disconnection-Preparation- 
for handover" . 

If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.3.2.2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.3.2.2.4 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control for GSM to UMTS Relocation as described in sub- 
clause 8.4.2.1.2.4. 

8.3.2.2.5 Handover Gommand/lu Relocation Detect 

When the MSC-1 server sends the Handover Command message or alternatively, if it receives the lu Relocation detect 
message inside a MAP Process- Access-Signalling request, the MSC-1 server shall follow the procedures described in 
sub-clause 8.4.2.1.2.5. 

8.3.2.2.6 lu Relocation Complete 

When the MSC-1 server receives the lu Relocation Complete message inside a MAP Send-End-Signalling Request and 
an ANSWER message including the LCLS status set to LCLS disconnected, it releases the A-interface line towards the 
serving BSS. The MSC-1 server also requests the MGW-1 to set the Handover Device to its final state by removing the 
bearer termination (Ts) towards the serving BSS. 

The MSC-1 server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS is disconnected. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS -Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Complete message received from the serving BSS also means LCLS is disconnected. 

8.3.2.3 Target MSC Server / Target MGW 

8.3.2.3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the lu Relocation Request message to the Target RNC as for the normal case. 
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8.3.2.3.2 Bearer establishment towards Target RNC 

The procedure specified in 3GPP TS 23.205 [2] sub-clause 8.3.2.2 shall be used. 

8.3.2.3.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 



8.3.2.4 



Example of Inter-MSC GSM to UMTS Relocation 



8.3.2.4.1 



Connection Model 



Figure 8.4.2.1.4.1.1 shows the network model for the Inter-MSC GSM to GSM Handover, where call leg UE-1 is 
handed over from BSS-1 to the Target RNC. BSS-1 is the same as BSS-2 when LCLS is established for the call. The 
BSS-1 is served by the MSC-Server 1, the Target RNC is served by the Target MSC-Server, and MSC-Server 1 is not 
the same as Target MSC-Server. The bearer termination T2 in MGW-2 is used for the bearer towards BSS-2, which is 
not affected by this handover. Bearer termination Ts in MGW-1 is used for the bearer towards BSS-1 and the bearer 
terminations Ta and T3 in MGW-1, Ti in MGW-2 and T4 in Target-MGW are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt in Target-MGW is for the bearer termination towards the Target 
RNC. 



User plane link which transmits real user plane data within BSS and to UE 

User plane link which transmits real user plane data through the ON and to UE 

User plane link path through ON, connected 

User plane uplink path through ON from Target BSS, connected 

Control plane link which transmits signalling 
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Connection Model 1 : Before handover, Local Switching is established 
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Connection Model 2: Before MSC triggers HO command to the BSS, T3 is isolated from Ts, Ta is one- 
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Connection Model 3: UE-1 not yet detected in Target RNC, BSS-2 bicasts user plane data UL 
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Connection Model 4: UE-1 connected to Target RNC but Target MSC-S has not received HO Detect 
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Connection Model 5: MSC-1 instructed MGW-1 to reroute the user plane, Ta is both-way connected to 
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Connection Model 6: Handover completed, Ts termination was removed 
Figure 8.3.2.4.1.1 : Inter-MSC GSM to UMTS Relocation Connection Model when user plane active 



8.3.2.4.2 



Basic Sequence for Inter-MSC handover that breaks Local Switching 



Figures 8.3.2.4.2.1 and 8.3.2.4.2.2 show the message sequence example for the basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.3.2.4.1.1. The Handover Device is located in the MGW- 
1 selected for the call establishment by the MSC-1 Server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.3.2.4.2.1: Inter-MSC GSM to UMTS Relocation that breaks Local Switching when user plane 

active, initial phase 

1. The Handover Required message is received from BSS-1 requesting an inter-MSC GSM to UMTS handover. 
The call is currently locally switched and the MSC-1 server knows that the Inter-MSC GSM to UMTS 
relocation at one end will break LCLS (the local switch is not broken in the serving BSS (BSS-1) until UE-l 
has moved out of the BSS-1 and the MSC-1 server sends the Clear Command message to BSS-1). 

2. The MSC-1 Server determines that inter-MSC handover is required and sends MAP-Prepare-Handover 
Request message to target MSC. 

3a, b. The Target MSC-Server requests Target MGW to provide a binding reference and a bearer address using the 
Prepare Bearer procedure when reserving Tt towards the Target RNC. 

4. The Target MSC-Server sends the lu Relocation Request message to Target RNC. 

5. The Target RNC sends the lu Relocation Acknowledge message to Target MSC-Server. 

6. The Target MSC-Server sends the Prepare Handover Response message to the MSC-1 server. 

7. The Anchor MSC-1 server may instruct the far end MSC-2 server to prepare for LCLS disconnection due to 
handover by sending the LCLS-Status-Change-Request message. (If the Anchor MSC-1 server does not 
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instruct the MSC-2 server /BSS-2 to prepare for LCLS disconnection for handover, BSS-2 starts bicasting 
user plane data to the core network after receiving the Handover Command message in Step 15.) 

8a. The far end MSC-2 server requests BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.3.2.4.1.1, 
Connection Model 3. This triggers the BSS-2 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send any DL data 
it receives directly to the served UE. 

NOTE 1: The Serving BSS-1 shall forward the user plane data received locally from UE-1 to UE-2 while the 
UE-1 is served by the BSS-1. BSS-2 bicasts UL user plane data to both MGW2 and local path and 
MGW-2 transmits the user plane data to MGW-1 and MGW-1 transmits the user plane data to the 
Target RNC via the Target MGW. When the UE-1 leaves the serving BSS-1 and begins sending 
UL data to the Target RNC via the Target MGW, that data will then be received via the A- 
interface leg at the serving BSS-2. 

8b. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

9a, b. In accordance with normal lu relocation in this example the MSC-1 server requests MGW-1 to isolate the 

termination towards Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the 
Anchor termination (Ta) one-way DL towards the Target MGW termination (T3). 

10. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledge message. 

11. MSC-1 Server sends lAM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 2: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 3: The MSC-1 Server can send lAM before receiving LCLS-Status-Change-Request- Acknowledge 
message. 

12a, b. Target-MSC-Server reserves bearer connection T4 towards MGW-1. 

13. After Target MGW has replied with the bearer address and the binding reference. Target MSC-Server returns 
APM with selected codec and LCLS-Negotiation IE. 

14. The Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing 
of the UE-1 on the radio path when the ACM is sent and the Anchor MSC-1 server initiates the lu relocation 
execution when receiving ACM. 
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Figure 8.3.2.4.2.2: Inter-MSC GSM to UMTS Relocation that breaks Local Switching when user p 
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15. MSC-1 server sends Handover Command message to BSS-1. 

16. BSS-1 sends Handover Command message to UE-1. BSS-1 will discard incoming user plane data send to 
UE-1 received from CN. If BSS-2 was not instructed to prepare for LCLS related handover in Step 8a, the 
BSS-2 starts bi-casting UP user plane data generated by UE-2 to local path and A interface and also starts to 
check whether there is incoming DL user plane data from the core network. 

NOTE 4: there is no situation where BSS-2 will receive real DL user plane data from the CN at the same 
time as it receives local data from UE-1 as part of the handover. 

17. UE-1 is detected at Target RNC. But still no UL data can be sent from Target RNC to MGW-1 because Ta- 
T3 is one-way DL only. MGW-1 will continue to transmit DL user plane data to the Target RNC. BSS-2 
continues to bi-cast user plane data to both local path and to the A interface. 

18. Target MSC-Server sends MAP-Process- Access-Signal request message to the MSC-1 server. 

19a, b. The MSC-1 server uses the Change Flow Direction procedure to request the MGW-1 to set the Handover 
Device to intermediate state and TA-T3 to both- way configuration. When BSS-2 finds out there is DL user 
plane data, BSS-2 will transmit the DL user plane data to UE-2. 

20. lu Relocation Complete message is received from Target RNC with LCLS -BSS -status indicating that the call 
cannot be locally switched. 

21. lu-Relocation-Complete message when received is included in the MAP SendEndSignalling Request 
message sent to the MSC-1 server. 
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22. Target MSC-Server sends ANSWER with the LCLS-status when lu-Relocation Complete message is 
received. 

23. MSC-1 server informs BSS-1 to clear the old call leg. 

24. Serving BSS-2 informs MSC-2 server that LCLS is broken via LCLS -Notification message. 

25. MSC-1 server sends LCLS Status Update message with LCLS status "LCLS disconnected" to MSC-2 server. 

NOTE 5: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

26. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released and BSS-2 stops bi-casting. 

NOTE 6: There is no need to send LCLS -Notification message from BSS-1 after receiving the Clear 
command since Clear Complete message indicates that LCLS was disconnected. 

27a, b. The MSC-1 server requests MGW-1 to set the Handover Device to its final state by removing the bearer 
termination Ts towards BSC-1 using the Release Termination procedure. 

8.4 GSM to GSM 

8.4.1 Intra-MSC Inter-BSS GSM to GSM Handover 

8.4.1 .1 Intra-MSC Inter-BSS GSM to GSM Handover that breaks Local Switching 

8.4.1.1.1 General 

When a call is locally switched through the BSS and an intra-MSC inter-BSS GSM to GSM handover occurs then the 
LCLS shall be broken and the user plane shall be connected through the core network. The intra-MSC inter BSS GSM 
to GSM handover procedures specified in 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The 
following clauses describe the additional requirements for intra-MSC inter BSS GSM to GSM handovers of LCLS 
related calls. 

During a Locally Switched (intra-BSS) Connection when no bicasting occurs there is no data transmission through the 
core network. In this release the use plane is kept active and therefore does not need to be re-activated when the LCLS 
is broken due to inter-BSS handover out of LCLS. 

8.4.1 .1 .2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. The MSC server shall use the Change Flow Direction procedure to request the MGW to set the Handover 
Device to the initial state. 

8.4.1 .1 .3 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control in the following ways: 

- In accordance with the normal handover case by isolating the termination to the Target BSS (Tt) from the 

termination to the Serving BSS (Ts) and configuring the Anchor termination (Ta) one-way DL to the Target BSS 
(Tt). Termination to the Serving BSS (Ts) is both way connected to Anchor termination (Ta) since it is also 
receiving UL user data from termination to the Serving BSS (Ts). 



Or: 



The MSC server may request the MGW to set termination to Target BSS (Tt) to both way connected to Anchor 
termination (Ta) and isolate termination to Serving BSS (Ts) completely. This improves the user plane switching 
and saves a signalling step to the MGW at Handover Detect message. The MSC server sends the Handover 
Request message to the Target BSS as for the normal case but shall include the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 
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8.4.1.1.4 Handover Request Acknowledge 

If the Target BSS supports LCLS feature then it shall include the LCLS-BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the anchor MSC Server that the BSS supports the LCLS feature, and therefore 
the MSC Server shall not act upon the status indicated, i.e. no signalling of LCLS-Status IE through the core network. 

Upon receipt of the Handover Request Acknowledge message the MSC Server shall send to the adjacent call node the 
LCLS -Status-Change-Request message to indicate "LCLS Disconnection-Preparation-for handover". 

If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.4.1 .1 .5 Handover Command/Handover Detect 

When the MSC server sends the Handover Command message or alternatively if it receives the Handover Detect 
message, if the MSC server followed the MGW control procedures for a non-LCLS call and kept the Termination to the 
Serving BSS connected then it shall use the Change Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state however if the MSC server isolated Ts and set Tt to both way through-connected then no 
MGW control procedure is required at this point. 

When the Handover Command message from the CN is received by the BSS, the BSS should start bi-casting the UL 
user plane data to the CN at the other call leg before sending Handover Command message to the MS, if the BSS did 
not receive an explicit indication on the other call leg to start bi-casting. 

8.4.1 .1 .6 Handover Complete 

When the MSC server receives the Handover Complete message, it releases the A-interface line towards the serving 
BSS. The MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination (Ts) towards the serving BSS. 

The MSC server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS disconnection. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS_Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Command message received from the serving BSS also means LCLS is disconnected. 

8.4.1.1.7 Example 

8.4.1 .1 .7.1 Connection Model 

Figure 8.4. L 1.7. 1.1 shows the network model for the Intra-MSC Inter-BSS GSM to GSM Handover, where the call leg 
pertinent to the UE-1 is handed over from the serving BSS-1 to the Target BSS. BSS-1 is the same as BSS-2 when 
LCLS is established for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected 
by this handover. Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Tl and Ta are 
used for the bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards 
the Target BSS. The colours and line types used in the figure are defined differently from 3 GPP TS 23.205 [2] to 
indicate LCLS specific issues. 
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Connection Model 1 : The call is locally switched 
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Tt = Target 

Connection Model 2: MGW-1 is both-way connected between Ta and Tt, Ts is isolated; BSS-2 starts 

to bicast data UL 
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Connection Model 3: UE has moved to Target BSS but HO Detect has not yet been received by MSC- 

S-1 
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UE-1 



After Handover 
Ta = Anchor 
Tt = Target 

Connection Model 4: LCLS is released in BSS-2, old serving Termination Ts is removed 
Figure 8.4.1.1.7.1.1: Intra-MSC Inter-BSS Handover Connection Model that breaks LCLS 
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8.4.1.1.7.2 



Basic Sequence for Inter-BSS Handover that breaks Local Switching 



UE-1 



BSS-1 



2. Conte):tC1: ADD 
Target BSS 



Break 

local 

switching 



MSC-S-1 



MGW-1 



1. HORecuired 



rermination for 
Tt) - bothway; 
MOD Ts Isolate 



Locally Switched User 



6. HO CMD 



10. C lear Command 



12. (>lear Complete 



13. Context C1: SUB Ts 



<t 



TargetBSS 



3. HO Request 
LCLS-Connection 



(GCR, LCLS-Configur|ation, 
Sitatus-Control = "Connect") 



4. HO Request Ack 
"Call not possible to 



(LCLS-BSS-StatLs: 
be locally switchejd") 



5. LCLS-Status-Ch£ 
"LCLS-Disconnectic n 
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Figure 8.4.1.1.7.2.1 : Intra-MSC Inter-BSS Handover that breaks Local Switching 

1. The Handover Required message is received from the BSS-1 requesting an inter-BSS handover. The call is 
currently locally switched so the MSC-1 server can know that the inter-BSS handover at one end will break 
local switch (the local switch is not broken in the serving BSS (BSS-1) until the UE-1 has moved out of the 
BSS-1 and the MSC-1 server sends the Clear Command message). 

2. In this example the Anchor MSC-1 server requests from its MGW-1 the seizure of the bearer termination Tt 
towards the Target BSS and through-connects it bothway to Ta. Additionally it isolates the old serving 
Termination Ts. This makes the handover much more efficient than even current non-LCLS handover as 
immediately the UE-1 moves into the new target BSS it will be able to send UL user data to the UE-2. 

NOTE 1: This flow shows the termination to the Target BSS as always connected bothway. This is a change 
to the existing call handling which would normally connect the termination as one-way and then 
change to bothway after receiving the Handover Detect message. However the termination does 
not need to be connected one-way and will in fact make the break in speech worse since UL data 
cannot be sent from the UE-1 until the MGW topology is modified, also it saves the additional 
intermediate H.248 modification step. 
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3. The Anchor MSC-1 server sends the Handover Request message to the Target BSS with the GCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE indicating "connect" to through- 
connect the local call. 

4. The Target BSS returns the Handover Request Acknowledge message and also indicates that call is not 
possible to be locally switched. 

5. The Anchor MSC-1 server sends the change in LCLS to the succeeding MSC server and the Anchor MSC-1 
server asks it to prepare for the LCLS disconnection for Handover to trigger sending of the LCLS-Connect- 
Control message at the far end MSC-2 server. 

NOTE 2: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

5a. The far end MSC-2 server requests the BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.4.1.7.1.1 
Connection Model 2. This triggers the BSS-2 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-2 shall send any DL data 
it receives directly to the served UE. Since the BSS-2 cannot receive DL data at the same time as it receives 
local data (Ts is isolated) this will minimise the break in user plane data even more than for existing non- 
LCLS handover. 

NOTE 3: The Serving BSS-1 shall forward the user plane data from the UE-1 to the UE-2 while the UE-1 is 
served by the BSS-1. The UL user plane data from UE-2 are bi-cast to both MGW2 and local path 
by the BSS-2. The MGW-2 transmits the user plane data to the MGW-1, and the MGW-1 will 
transmit the user plane data to the target BSS. When the UE-1 leaves the serving BSS-1 and begins 
sending UL data from the Target BSS, that data will then be received via the A-interface leg at the 
serving BSS-2. 

NOTE 4: Possible bicasting may have been activated earlier when LCLS was established in the BSS-1 

/BSS-2 (not shown in the figure 8.4.1.8.2.1) and was indicated with the LCLS -Configuration IE in 
step 3 and applies to both call legs. If LCLS bicasting was not activated the LCLS -Configuration 
value is "Connect" (i.e. no bicasting) in step 3, but the value of the LCLS-Connection-Status- 
Control in step 5 is "BicastatHandover", which applies only for this call leg. 

5b. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

6. The Anchor MSC-1 server triggers the Handover Command message. When the UE-1 moves to the Target 
BSS in this example it can immediately send UL data through the CN to the UE-2 and also can receive DL 
data from the UE-2 via the CN since the MGW-1 topology for Ta, Tt is already both way connected. This is a 
change from the current non-LCLS solution but is more efficient since the non-LCLS solution needs to set 
this to one-way DL only until it receives Handover Detect message. 

7. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

8. The UE-1 is detected at the target BSS. The BSS-l/BSS-2 may continue to send the user plane data locally 
until the Clear Command message is received. 

9. In the Handover Complete message the Target-BSS indicates to the MSC-1 server in the LCLS -BSS -Status 
IE that the call is not possible to be locally switched. 

10. The MSC-1 server requests the old serving BSS-1 to clear the old call leg. The BSS-1 now stops sending 
local the user data from UE-1, LCLS is finally broken. 

11. The Serving BSS-2 informs the MSC-2 server that LCLS is broken via LCLS_Notification message. 

12. Clearing of the old call leg to the Serving BSS-1 is completed.. 

13. The termination Ts to the old serving BSS-1 is removed from the Access MGW-1. 

14. The Anchor MSC-1 server informs succeeding CN nodes that LCLS is finally disconnected. 

NOTE 5: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 
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LCLS is impossible after an Inter-BSS handover which makes the call not local (as described above). While a handover 
is being performed for one call leg, it is possible that a handover also is started for the other call leg, possibly moving 
both call legs to the same target BSS, thereby creating a local call. The target BSS shall only establish LCLS for a local 
call when both call legs are connected and e.g. any handover process has been successfully completed on both call legs. 

8.4.1 .2 Intra-MSC Inter-BSS GSM to GSM Handovers that establishes Local 

Switching 

8.4.1.2.1 General 

When LCLS is not established for a call and an intra-MSC inter-BSS GSM to GSM handover occurs that makes the call 
local, the call should be locally switched in the BSS. The Intra-MSC inter-BSS GSM to GSM handover procedures 
specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The following 
clauses describe the additional requirements for intra-MSC handovers that establish LCLS. 

8.4.1 .2.2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. The MSC server shall use the Change Flow Direction procedure to request the MGW to set the Handover 
Device to the initial state. 

8.4.1 .2.3 Bearer establishment towards Target BSS 

When the MSC-Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if AoTDM 
using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point procedure as for 
the normal handover procedure. The MSC-Server sends the Handover Request message to the Target BSS containing 
the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.4.1 .2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target BSS (Tt) from the 
termination to the Serving BSS (Ts) and configures the Anchor termination (Ta) one-way DL towards the Target BSS 
termination (Tt). Termination to the Serving BSS (Ts) is both- way connected to Anchor termination (Ta) since it is also 
receiving UL user data from termination to the Serving BSS (Ts). 

8.4.1 .2.5 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the anchor MSC Server that the BSS supports the LCLS feature. 

The anchor MSC Server shall not act upon the status indicated, i.e. no signalling of LCLS-Status IE through the core 
network. 

8.4.1 .2.6 Handover Command/Handover Detect 

The anchor MSC Server shall use the Change Flow Direction procedure to requests the MGW-1 to set the Handover 
Device to intermediate state. 

8.4.1 .2.7 Handover Complete 

When the MSC-Server receives the Handover Complete message, it releases the A-interface line towards the serving 
BSS. The MSC-Server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination towards the serving BSS. 

When LCLS has been established during the handover procedure, the target BSS informs the anchor MSC-Server that 
the call has been locally switched in the Handover Complete message. 

The MSC-Server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating that LCLS was established. 
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8.4.1.2.8 



Example 



8.4.1.2.8.1 



Connection Model 



Figure 8.4.1.2.8.1.1 shows the network model for the Intra-MSC Inter-BSS GSM to GSM Handover, where the call leg 
pertinent to the UE-1 is handed over from the serving BSS-1 to the Target BSS. Target ESS is the same as BSS-2 when 
LCLS is established for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected 
by this handover. Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are 
used for the bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards 
the Target BSS. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to 
indicate LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the ON and to UEs 

• • • User plane path through the ON, connected 

www Control plane link which transmits signalling 



UE-2 



UE-1 




Connection Model 1 : Before handover 
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Connection Model 2: During handover, Ts and Ta are both-way connected, Tj is isolated from Ts 
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Connection Model 3: UE has moved to Target BSS but HO Detect has not yet been received by MSC- 
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MGW-2y 



MGW-1 



Connection Model 4: The call is locally switched 
Figure 8.4.1 .2.8.1 .1 : Connection Models for Inter-BSS Handover that establishes Local Switching 



8.4.1.2.8.2 



Basic Sequence for Inter-BSS Handover that breaks Local Switching 



Figures 8.4.1.2.8.2.1 and 8.4.1.2.8.2.2 show the message sequence example for the Basic Intra-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.1.2.8.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-1 server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.1.2.8.2.1 : Inter-BSS Handover that establishes Local Switching 

1. Handover Required message is received from BSS-1 requesting an inter-MSC handover. The call is currently 
not locally switched. 

2. MSC-1 Server determines that an intra-MSC handover is required and checks that LCLS negotiation in the 
core network permitted LCLS. The MSC-1 Server reserves a new Termination for Target BSS and configures 
this as one-way connected to the Anchor Termination (as per existing handover procedures). 

3. MSC-1 Server sends Handover Request message to target BSS with GCR and instructs the BSS to prepare to 
connect LCLS. The LCLS-Configuration IE can instruct the BSS to bi-cast user plane data, if applicable. 

4. Target BSS performs call leg correlation with GCR to find if another call leg is active with the same GCR. 
The BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not 
yet established. 

5a, b. (These signalling steps are only applicable to AoIP.) MSC-1 Server sends the IP address and UDP Port 
number of the Target BSS to MGW-1 using the Configure RTP Connection Point procedure. 

6. MSC-1 Server sends the Handover Command message. 
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7. UE-1 gets connected to the Target BSS, which sends Handover Detect. 

8a, b. In accordance with normal handover the MSC-1 Server requests MGW-1 to isolate the termination towards 
Target BSS (Tt) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target BSS termination (Tt). 

9. Target BSS indicates in the Handover Complete message that the call is locally switched. 

10. BSS-2 sends the LCLS_Notification message to MSC-2 Server with the LCLS-BSS-Status IE set to "call is 
locally switched" . 

11. MSC-1 Server requests the old serving BSS-1 to clear the old call leg. 

12. Clearing of the old call leg to the Serving BSS-1 is completed. 

13. The termination Ts to the old serving BSS-1 is removed from MGW-1. 

14. MSC-1 Server informs succeeding CN nodes that LCLS is connected. 

NOTE: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

LCLS becomes possible after an Inter-BSS handover which makes the call local (as described above). While a handover 
is being performed for one call leg, it is possible that a handover also is started for the other call leg, possibly moving 
that call leg to another BSS and in that case the call does not become local. The target BSS shall only establish LCLS 
for a local call when both call legs are connected and e.g. any handover process has been successfully completed on 
both call legs. 

8.4.2 Inter-MSC GSM to GSM Handover 

8.4.2.1 Inter-MSC GSM to GSM Handover that breaks Local Switching 

8.4.2.1.1 General 

If LCLS is established for a call and an inter-MSC GSM to GSM handover occurs that makes the call not local the 
LCLS shall be broken in the BSS and the user plane data shall be connected through the core network. The Inter-MSC 
GSM to GSM handover procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] 
shall be followed. The following clauses describe the additional requirements for inter-MSC handovers of LCLS related 
calls. 

8.4.2.1.2 MSC-1 /MGW-1 

8.4.2.1 .2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call and LCLS negotiation IE to the Target MSC 
Server in a MAP Prepare-Handover_Request message. 

8.4.2.1 .2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS-BSS-Status IE the Anchor MSC-1 Server shall send to the adjacent call node, MSC-2 Server, the 
LCLS -Status-Change Request message containing the LCLS -Status-Change-Request IE to signal the change of LCLS 
status. In the LCLS -Status-Change-Request IE the MSC-1 server shall indicate "LCLS Disconnection-Preparation-for 
handover" . 

If the MSC-2 Server receives the LCLS -Status-Change Request message with the LCLS -Status-Change-Request IE that 
requires LCLS Disconnection preparation-for-handover it shall send to BSS-2 the LCLS_Connect_Control message 
with the LCLS -Connection-Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control 
acknowledge message is received from the BSS-2, the MSC-2 server shall return the LCLS Status Change Request 
Acknowledge message indicating "LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS 
Status Change Request accepted. 
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8.4.2.1 .2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.4.2.1 .2.4 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control in the following ways: 

In accordance with the normal handover case by isolating the termination in MGW-1 towards the Target MGW 
(T2) from the termination to the Serving BSS (Ts) and configuring the Anchor termination (Ta) one-way DL 
towards the Target MGW termination (T2). Termination to the Serving BSS (Ts) is both- way connected to 
Anchor termination (Ta) since it is also receiving UL user data from termination to the Serving BSS (Ts). The 
basic example in sub-clause 8.4.2.1.4 illustrates this type of functionality. 

Or: 

- The MSC-1 Server may request the MGW-1 to set termination towards Target-MGW (T2) to both- way 

connected to Anchor termination (Ta) and isolate termination to Serving BSS (Ts) completely. This improves the 
user plane switching and saves a signalling step to the MGW-1 at Handover Detect message. 

8.4.2.1 .2.5 Handover Command/Handover Detect 

When the MSC-1 server sends the Handover Command message or alternatively if it receives the Handover Detect 
message inside a MAP Process- Access-Signalling request, if the MSC-1 server followed the MGW control procedures 
for a non-LCLS call and kept the Termination to the Serving BSS connected then it shall use the Change Flow 
Direction procedure to requests the MGW-1 to set the Handover Device to intermediate state, however if the MSC 
server- 1 isolated Ts and set T2 to both way then no MGW control procedure is required at this point. 

8.4.2.1 .2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the A-interface line towards BSS-1. The 
MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the bearer termination 
towards the BSS-1. 

After the MSC-1 Server receives the Answer message including the LCLS-Status set to LCLS feasible but not yet 
locally switched, MSC-1 Server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS- 
Status IE indicating that LCLS is not established. 

8.4.2.1 .3 Target MSC Server / Target MGW 

8.4.2.1 .3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the Handover Request message to the Target BSS as for the normal case but shall include the GCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE set to "Connect". 

8.4.2.1 .3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.4.2.1 .3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 
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8.4.2.1.3.4 



Bearer establishment between MGW-1 and Target MGW 



The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 



8.4.2.1.3.5 



LCLS Negotiation in Initial Address message 



If the Target MSC Server receives an Initial Address message that does not include a LCLS -Negotiation IE or includes 
a LCLS -Negotiation IE set to LCLS is not permitted, the Target MSC Server shall update the previously sent LCLS- 
Configuration by sending a LCLS_CONNECT_CONTROL message to BSS with a LCLS -Configuration IE set to 
LCLS-not allowed and a LCLS Connection Status Control IE set to "do not connect LCLS". 



8.4.2.1.4 



Example of Inter-MSC Handover that breaks Local Switching 



8.4.2.1.4.1 



Connection Model 



Figure 8.4.2.1.4.1.1 shows the network model for the Inter-MSC GSM to GSM Handover, where call leg UE-1 is 
handed over from BSS-1 to the Target BSS. BSS- 1 is the same as BSS-2 when LCLS is established for the call. The 
BSS-1 is served by the MSC-Server 1, the Target BSS is served by the Target MSC-Server, and MSC-Server 1 is not 
the same as Target MSC-Server. The bearer termination T2 in MGW-2 is used for the bearer towards BSS-2, which is 
not affected by this handover. Bearer termination Ts in MGW-1 is used for the bearer towards BSS-1 and the bearer 
terminations Ta and T3 in MGW-1, Ti in MGW-2 and T4 in Target-MGW are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tx in Target-MGW is for the bearer termination towards the Target 
BSS. 
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Connection Model 1 : Before handover, LCLS is established 
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Connection Model 3: UE-1 not yet detected in Target BSS, BSS-2 bicasts user plane data UL 
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Connection Model 4: UE-1 connected to Target BSS but Target MSC-S has not received HO Detect 




•/- 



MSC-l S 



''TS^'""S2r" 



MSC-2 S 






-• \ 



\ C Target 

%Lmsc-; 



J L 

Target BSS 




• ATs< >Ta 



MGW-iy 



MGW-2 



Target 
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Connection Model 6: Handover completed, Ts termination was removed 
Figure 8.4.2.1.4.1.1 : Inter-MSC Inter-BSS Handover Connection Model when user plane active 



8.4.2.1.4.2 



Basic Sequence for Inter-MSC handover that breaks Local Switching 



Figures 8.4.2.1.4.2.1 and 8.4.2.1.4.2.2 show the message sequence example for the basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.2.1.4.1.1. The Handover Device is located in the 
MGW-1 selected for the call establishment by the MSC-1 Server, which controls the call and the mobility management. 
The description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.2.1.4.2.1 : Inter-MSC Handover that breaks LCLS when user plane active, initial phase 

1. The Handover Required message is received from BSSl requesting an inter-MSC handover. The call is 
currently locally switched and the MSC-1 server can know that the Inter-MSC handover at one end will 
break LCLS (the local switch is not broken in the serving BSS (BSS-1) until UE-l has moved out of the 
BSS-1 and the MSC-1 server sends the Clear Command message to BSS-1). 

2. The MSC-1 Server determines that inter-MSC handover is required and sends MAP-Prepare-Handover 
Request to target MSC which includes LCLS Negotiation and GCR IBs. 

3a, b. The Target MSC-Server reserves circuit or Connection Point Tt towards the Target BSS. 

4. The Target MSC-Server sends the Handover Request message to target BSS with the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

5. The Target BSS reports in Handover Request Acknowledge message that the call is not possible to be locally 
switched. 
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6a, b. (These signalling steps are only applicable to AoIP) When the Target MSC-Server receives the BSSMAP 
Handover Request- Ack message, it sends the target BSC IP address and UDP Port number to the target 
MGW using the Configure RTP Connection Point procedure. 

7. The Target MSC-Server sends the Prepare Handover Response message to the MSC-1 server. 

8a. The Anchor MSC-1 server instructs the far end MSC-2 server to prepare for LCLS disconnection for 
Handover by sending the LCLS-Status-Change-Request message. 

8b. The far end MSC-2 server requests BSS-2 to start sending data UL with the LCLS_Connect_Control 
message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 
8.4.2.1.4.1.1, Connection Model 3. This triggers the BSS-2 to bicast the user plane data in the same way as 
the Access MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send 
any DL data it receives directly to the served UE. 

NOTE 1: The Serving BSS-1 shall forward the user plane data received locally from UE-1 to UE-2 while the 
UE-1 is served by the BSS-1. BSS-2 bicasts UL user plane data to both MGW2 and local path and 
MGW-2 transmits the user plane data to MGW-1 and MGW-1 transmits the user plane data to the 
Target BSS via the Target MGW. When the UE-1 leaves the serving BSS-1 and begins sending 
UL data to the Target BSS via the Target MGW, that data will then be received via the A-interface 
leg at the serving BSS-2. 

NOTE 2: Possible bicasting may have been activated earlier when LCLS was established in the BSS-1 

/BSS-2 (not shown here) and was indicated with the LCLS -Configuration IE in step 4 and applies 
to both call legs. If LCLS bicasting was not activated the LCLS -Configuration value is "Connect" 
(i.e. no bicasting) in step 4, but the value of the LCLS-Connection-Status-Control in step 8b is 
"BicastatHandover", which applies only for this call leg. 

8c. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

8d. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledge message. 

NOTE 3: Handover sequence is independent of the LCLS-Status-Change-Request- Acknowledge message. 

9a, b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 
Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target MGW termination (T3). 

10. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 4: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

1 la, b. Target-MSC-Server reserves bearer connection T4 towards MGW-1. 

12. After Target MGW has replied with the bearer address and the binding reference. Target MSC-Server returns 
Bearer and Codec Information (APM) message with selected codec, available codec list and LCLS- 
Negotiation IE. 

13. The Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing 
of the UE-1 on the radio path when the ACM is sent and the Anchor MSC-1 server initiates the handover 
execution when receiving ACM. 
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Figure 8.4.2.1.4.2.2: Inter-MSC Handover that breaks LCLS when user plane active, completion phase 

14. MSC-1 server sends Handover Command message to BSS-1. 

15. BSS-1 sends Handover Command message to UE-1. BSS-1 will discard incoming user plane data send to 
UE-1 received from CN. If BSS-2 was not instructed to prepare for LCLS related handover in Step 8a, the 
BSS-2 starts bi-casting UP user plane data generated by UE-2 to local path and A interface and also starts to 
check whether there is incoming DL user plane data from the core network. 

NOTE 5: there is no situation where BSS-2 will receive real DL user plane data from the CN at the same 
time as it receives local data from UE-1 as part of the handover. 

16. UE-1 is detected at target BSS. But still no UL data can be sent from target BSS to MGW-1 because Ta-Ts is 
one-way DL only. MGW-1 will continue to transmit DL user plane data to the target BSS-1. BSS-2 continues 
to bi-cast user plane data to both local path and to the A interface. 

17. Target MSC-Server sends MAP-Process- Access-Signal request to the MSC-1 server. 

18a, b. The MSC-1 server uses the Change Flow Direction procedure to request the MGW-1 to set the Handover 
Device to intermediate state and TA-T3 to both- way configuration. When BSS-2 finds out there is DL user 
plane data, BSS-2 will transmit the DL user plane data to UE-2. 

19. Handover Complete message is received from target BSS with LCLS -BSS -status indicating that the call 
cannot be locally switched. 

20. A Handover-Detect/Complete when received is included in the MAP SendEndSignalling Request message 
sent to the MSC-1 server. 
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21. Target MSC-Server sends ANSWER message with the LCLS-status when a Handover-Detect/Complete is 
received. 

22. MSC-1 server informs BSS-1 to clear the old call leg. 

23. MSC-1 server sends LCLS Status Update message with LCLS status "LCLS disconnected" to MSC-2 server. 

NOTE 6: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

24. Serving BSS-2 informs MSC-2 server that LCLS is broken via LCLS -Notification message. 

NOTE 7: There is no need to send LCLS -Notification message from BSS-1 after receiving the Clear 
Command message since Clear Complete indicates that LCLS was disconnected. 

25. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released and BSS-2 stops bi-casting. 

26a, b. The MSC-1 server requests MGW-1 to set the Handover Device to its final state by removing the bearer 
termination Ts towards BSC-1 using the Release Termination procedure. 

8.4.2.2 Inter-MSC GSM to GSM Handover that establishes Local Switching 

8.4.2.2.1 General 

When LCLS is not established for a call and an inter-MSC handover occurs that makes the call local, the call should be 
locally switched in the BSS. The Inter-MSC handover procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 
[2] and 3GPP TS 23.231 [3] shall be followed. The following clauses describe the additional requirements for inter- 
MSC handovers that establish LCLS and the differences compared to Inter-MSC handovers that break LCLS are 
identified. 

8.4.2.2.2 MSC-1 / MGW-1 

8.4.2.2.2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call and LCLS negotiation IE to the Target MSC 
Server in a MAP Prepare-Handover_Request message. 

8.4.2.2.2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS -BSS -Status IE the Anchor MSC-1 Server configures the bearer terminations in MGW-1 and 
sends the GCR and LCLS -Negotiation information to the target MSC-Server. 

8.4.2.2.2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.4.2.2.2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target MGW (T2) from 
the termination to the Serving BSS (Ts) and configures the Anchor termination (Ti) one-way DL towards the Target 
MGW termination (T2). Termination to the Serving BSS (Ts) is both-way connected to Anchor termination (Ti) since it 
is also receiving UL user data from termination to the Serving BSS (Ts). 

8.4.2.2.2.5 Handover Command/Handover Detect 

The MSC-1 Server shall use the Change Flow Direction procedure to requests the MGW-1 to set the Handover Device 
to intermediate state. 
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8.4.2.2.2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the A-interface line towards BSS-1. The 
MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the bearer termination 
towards the BSS-1. 

When LCLS has been established during the handover procedure, the target ESS informs the target MSC-Server that 
the call has been locally switched in the Handover Complete message, 

8.4.2.2.3 Target MSG Server / Target MGW 

8.4.2.2.3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the Handover Request message to the Target BSS as for the normal case but shall include the OCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE set to "Connect". 

8.4.2.2.3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.4.2.2.3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.4.2.2.3.4 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 

8.4.2.2.3.5 LCLS Negotiation in Initial Address message 

If the Target MSC Server receives an Initial Address message that does not include a LCLS -Negotiation IE or includes 
a LCLS -Negotiation IE set to LCLS is not permitted, the Target MSC Server shall update the previously sent LCLS- 
Configuration by sending a LCLS_CONNECT_CONTROL message to BSS with a LCLS -Configuration IE set to 
LCLS-not allowed and a LCLS_Connection_Status_Control IE set to "do not connect LCLS". The inter-MSC handover 
continues as described in sub-clause 8.4.2.3 Inter-MSC Handover that leaves a not locally Switched Call unchanged. 

8.4.2.2.4 Example of Inter-MSC Handover that establishes Local Switching 

8.4.2.2.4.1 Connection Model 

Figure 8.4.2.2.4.1.1 shows the network model for the Basic Inter-MSC GSM to GSM handover when LCLS is 
established as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards BSS-1, bearer termination Ta is used for the bearer towards the 
succeeding/preceding MGW, that is MGW-2 and bearer termination T3 is used towards the Target MGW. In MGW-2 
the bearer termination T2 is used for the bearer towards BSS-2 and bearer termination Ti is used for the bearer towards 
MGW-1. In Target-MGW the bearer termination Tt is used towards the Target-BSS and bearer termination T4 is used 
towards MGW-1. 

In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 
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8.4.2.2.4.2 



Figure 8.4.2.2.4.1.1 : Basic Inter-MSC GSM to GSM Handover (network model) 



Basic Sequence 



Figures 8.4.2.2.4.2.1 and 8.4.2.2.4.2.2 show the message sequence example for the Basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.2.2.4.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-1 server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.2.2.4.2.1 : Initial phase of Inter-MSC Handover establishing Local Switching 

Handover Required message is received from BSS-1 requesting an inter-MSC handover. The call is currently 
not locally switched. 

The MSC-1 server determines that inter-MSC handover is required and sends the Pre-Handover Request 
message to target MSC-Server which includes LCLS Negotiation and GCR. 



3a, b. Target-MSC-Server reserves circuit or Connection Point towards the Target-BSS 

4. Target MSC-Server sends Handover request message to target BSS with GCR and instructs the BSS to 
prepare to connect LCLS. The LCLS -Configuration IE can instruct the BSS to bi-cast user plane data, if 
applicable. 
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5. Target BSS performs call leg correlation with GCR to find if another call leg is active with same GCR. The 
BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not yet 
established. 

6a, b. (These signalling steps are only applicable to AoIP.) When the Target MSC-Server receives the BSSMAP 

Handover Request- Ack message, it sends the BSC-B IP address and UDP Port number to the MGW-B using 
the Configure RTP Connection Point procedure. 

7. The Target MSC-Server sends the Prepare Handover Response message to MSC-1 server. 

8. b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 

Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target MGW termination (T3). 

9. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 1: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 2: The LCLS-Negotiation IE in step 9 can be different from LCLS Negotiation IE in step 2, because 
step 9 is BICC signalling and the IE value can be changed by intermediate MSC-Servers. 

10a, b. Target MSC-Server reserves bearer connection T4 towards MGW-1. 

11. After Target MGW has replied with the bearer address and the binding reference (Step 10b), the Target 
MSC-Server returns the Bearer and Codec Information (APM) message with selected codec, available codec 
Hst and the LCLS-Negotiation IE. 

12. Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing of 
the UE-1 on the radio path when the ACM is sent and MSC-1 server initiates the handover execution when 
receiving ACM. 
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Figure 8.4.2.2.4.2.2: Completion phase of Inter-MSC Handover establishing Local Switching 

13-18. When the local switching has been established during the handover procedure, the target BSS shall inform 
the target MSC-Server that the call has been locally switched in Handover Complete message, and the target 
BSS shall also send a new message LCLS -Notification with LCLS-BSS-Status IE to inform the MSC-2 
server that the local switching has been established. In steps 16a and 16b the MSC-1 server configures 
MGW-1 for the completion of the handover. 

19. A Handover-Detect/Complete when received is included in the MAP- S end-End- Signal request and send back 
to the MSC-1 server. 

20. Target MSC-Server sends ANSWER message with the LCLS-status when A-HO-DETECT/COMPLETE is 
received. 

21. MSC-Server 1 clears the call in BSS-1. 

22. MSC-1 server (Anchor MSC-Server) sends LCLS -Status-Update message to the far end MSC-2 server. 

NOTE 3: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

23. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released 
24a, b. MSC-1 server releases the bearer termination towards BSS-1. 

25. Local switching is established in the BSS. 
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8.4.2.3 Inter-MSC Handover that leaves a not Locally Switched Call unchanged 

In this scenario it is assumed that LCLS was not estabhshed before the Inter-MSC handover. When one call leg is 
handed over to another MSC-Server, the call still remains not local. LCLS cannot be established for the call and the 
LCLS status of the call is not changed. 

For the Anchor MSC-1 server and Target MSC server this Inter-MSC handover is similar to the Inter-MSC handover 
that establishes LCLS as described in sub-clause 8.4.2.2.4.2 until Step 5, but in this case in Step 5 the Target BSS sends 
the Handover Request ACK message, where the LCLS -BSS -Status IE indicates that the call is not possible to be locally 
switched since the GCR correlation will indicate that the call is not local. The handover procedure is completed as for a 
non-local call, LCLS is not established and the LCLS Status in the core network is not changed. 

8.4.3 Subsequent Inter-MSC GSM to GSM Handover back to the Anchor 
MSC 

The basic Inter-MSC GSM to GSM handover procedure as specified in this specification shall be applied. 

8.4.4 Subsequent GSM to GSM Handover to a third MSC 

The basic GSM to GSM handover procedure as specified in this specification shall be applied. 

8.4.5 BSS Internal Handover 

8.4.5.1 General 

The following procedures describe the specific handling compared to the basic principles described in 3GPP TS 23.205 
[2] sub-clause 8.4.5 to achieve BSS Internal Handover with LCLS for an A-interface User Plane over IP (AoIP). 

If the call is not locally switched but both call legs have been correlated and an internal handover occurs that makes the 
call local, the call should be locally switched in the BSS. 

If a call is currently locally switched and an internal handover occurs that makes the call not local, the local switching 
should be broken in the BSS and the user plane data shall be connected through the core network. 

NOTEl : For A-interface User Plane over TDM (AoTDM), a BSS internal handover that results in LCLS break will 
trigger a BSS Initiated LCLS Break according to procedures in sub-clause 7.2.2. 

If an internal handover procedure occurs that does not modify the LCLS status of a call, the local switching should not 
be modified within the BSS. 

8.4.5.2 Internal Handover Required 

If the MSC Server accepts the Internal Handover Required message it shall send an Internal Handover Command 
message to the BSS. If the call is currently locally switched in the BSS, the MSC Server shall also signal LCLS-Status- 
Change Request message containing LCLS -Status-Change IE set to "LCLS Disconnection Preparation for Handover" 
through the core network to enable UL bi-casting during handover. 

The MSC Server shall not wait for the LCLS-Status-Change Request Acknowledge message before proceeding with the 
Internal Handover. 

8.4.5.3 Internal Handover Command 

If local switching is permitted by the core network and the MSC Server has not previously requested that the BSS 
should connect the local call, (e.g. no previous LCLS-Connection-Status-Control = "Connect"), the MSC Server shall 
include the LCLS-Connection-Status-Control IE indicating "Connect" in the Internal Handover Command message. 

Otherwise, the MSC Server shall send the Internal Handover Command message according to the procedures in 3GPP 
TS 48.008 [7]. 
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8.4.5.4 



Handover Complete 



The BSS sends Handover Complete message including the LCLS-BSS -Status that indicates whether the call is locally 
switched (e.g. "Call is Locally Switched" or "Locally switched call is no longer locally switched"). 

The MSC server shall send to an adjacent call node the LCLS-Status-Update message with the LCLS-Status IE 
indicating the new LCLS Status (e.g. "LCLS connected" or "LCLS Not Connected"). 

8.4.5.5 Example BSS Internal Handover that Establishes Local Switching 

8.4.5.5.1 Connection Model 

Figure 8.4.5.5.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tx is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 
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Connection Model 1 : Before BSS Internal Handover - Call is not locally switched 
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Connection Model 3: After BSS Internal Handover - Call is Locally Switched 
Figure 8.4.5.5.1.1: BSS Internal Handover Connection Model that Establishes Local Switching 



8.4.5.5.2 



Basic Sequence for BSS Internal Handover that Establishes Local Switching 



Figure 8.4.5.5.2.1 shows the message sequence example for the BSS Internal Handover that Establishes Local 
Switching. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.5.2.1 : BSS Internal Handover for AolP that Establishes Local Switching 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 

Handover Command message, including the LCLS -Connection-Control-Status message indicating "Connect" 
if not previously indicated to BSS- L 

4-5. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

6. The Handover Complete message includes the LCLS-BSS-Status IE indicating that call is locally switched. 

NOTE: alternatively the BSS-1 could indicate LCLS-BSS-Status IE in LCLS -Notification message. 

7-9. The LCLS Status is propagated through the Core Network. 

8.4.5.6 Example BSS Internal Handover that Breaks Local Switching 



8.4.5.6.1 



Connection Model 



Figure 8.4.5.6.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
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bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 
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Connection Model 3: After BSS Internal Handover - Call is not Locally Switched 
Figure 8.4.5.6.1.1: BSS Internal Handover Connection Model that Breaks Local Switching 

8.4.5.6.2 Basic Sequence for BSS Internal Handover that Breaks Local Switching 

Figure 8.4.5.6.2.1 shows the message sequence example for the BSS Internal Handover that Breaks Local Switching. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.6.2.1 : BSS Internal Handover for AolP that Breaks Local Switching 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. MSC-1 Server indicates preparation for disconnection due to handover through the Core Network. 
MSC-2 Server indicates to BSS-2 to start UL bicasting. 



3a. 
3b. 

3c. 
4. 

4a 

5. 



The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command message, optionally including the LCLS -Connection-Control- Status message indicating 
"Connect". 

BSS-1 may indicate Handover Detected. 

BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "Call 
is no longer locally switched" . 



6. MSC-1 Server propagates the change of the LCLS Status through the Core Network. 

NOTE: If the Internal Handover did not in the end result in LCLS break then the MSC Server will send 
LCLS-Status-Update message indicating that the call is locally switched. 

7. BSS-2 indicates that the call is no longer locally switched in the LCLS_NOTIFICATION message. 
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8. The old termination (Ts) is removed and the call is normally switched through the Core Network. 

8.4.5.7 Example BSS Internal Handover that Does Not Modify LCLS Status of a 

Locally Switched Call 

8.4.5.7.1 Connection Model 

Figure 8.4.5.7.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 
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Figure 8.4.5.7.1.1 : BSS Internal Handover Connection Model that Does Not Modify LCLS Status of a 

Locally Switched Call 

8.4.5.7.2 Basic Sequence for BSS Internal Handover that Does Not Modify LCLS Status of 

a Locally Switched Call 

Figure 8.4.5.7.2.1 shows the message sequence example for the BSS Internal Handover that Does Not Modify LCLS 
Status of a Locally Switched Call. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.7.2.1 : BSS Internal Handover for AolP that Does Not Modify LCLS Status of a Locally 

Switched Call 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. MSC-1 Server indicates preparation for disconnection due to handover through the Core Network. 
MSC-2 Server indicates to BSS-2 to start UL bicasting. 



3a. 
3b. 

3c. 
4. 

4a 

5. 



The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command message, optionally including the LCLS -Connection-Control- Status message indicating 
"Connect". 

BSS-1 may indicate Handover Detected. 

BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "Call 
is locally switched" . 



6. The old termination (Ts) is removed and the call is normally switched through the Core Network. 
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8.4.5.8 Example BSS Internal Handover that Does Not Modify LCLS Status of a non- 

Locally Switched Call 

8.4.5.8.1 Connection Model 

Figure 8.4.5.8.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tx is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 
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Figure 8.4.5.8.1.1 : BSS Internal Handover Connection Model that Does Not Modify LCLS Status of a 

non-Locally Switched Call 

8.4.5.8.2 Basic Sequence for BSS Internal Handover that Does Not Modify LCLS Status of 

a non-Locally Switched Call 

Figure 8.4.5.8.2.1 shows the message sequence example for the BSS Internal Handover that Does Not Modify LCLS 
Status of a Locally Switched Call. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.8.2.1 : BSS Internal Handover for AolP that Does Not Modify LCLS Status of a non-Locally 

Switched Call 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command, optionally including the LCLS-Connection-Control-Status message indicating 
"Connect". 

3a BSS-1 may indicate Handover Detected. 

4. BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "Call 
is not locally switched" . 

5. The old termination (Ts) is removed and the call is normally switched through the Core Network. 

8.5 Handling of GSM Services after UMTS to GSM Handover 

No impact. There are no LCLS related requirements for the handling of GSM Services after UMTS to GSM Handover. 

The handling of GSM services after UMTS to GSM Handover shall be applied in accordance with 3GPP TS 23.205 [2] 
sub-clause 8.5 for Bearer-Independent CS Core Networks. 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 129 ETSI TS 123 284 VI 0.1.0 (2011-06) 

9 Compatibility Issues 

None; this feature is backward compatible with existing features and earUer releases. 

1 General (G)MSC server-MGW Procedures 

LCLS does not modify the general (G)MSC server-MGW procedures as shown in 3GPP TS 23.205 [2]. 



1 1 Identities 

11.1 General 

The Identities defined in 3GPP TS 23.205 [2] for BIGG based GS Gore network and in 3GPP TS 23.231 [3] for SIP-I 
with the following additions. 

1 1 .2 Global Call Reference 

The Global Gall Reference (GGR) IE is derived from the ITU-T Global Call Reference parameter (defined by ITU-T 
Q.1902.3 [5]). 

The Global Gall Reference (GGR) information element is a combination of a Network ID field, a Node ID field and a 
Gall Reference ID field. The Gall Reference ID field for LGLS is defined to contain a unique call ID. 

If the serving radio access is GERAN the Gall Reference ID subfield created by originating MSG server contains a 
unique call ID and the originating BSS ID which is a unique identifier of a Base Station Subsystem (BSS) Node within 
an operator's network. 

The complete parameter layout is specified in 3GPP TS 29.205 [6]. 

The GGR is exchanged on the Nc and A interfaces to globally identify the call. 



1 2 Operational Aspects 
12.1 Charging 

No impact. 



1 3 Interactions with Other Services 

13.1 Enhanced Multi-Level Precedence and Pre-emption service 
(eMLPP) 

No impact. eMLPP is always done during call set-up and handled by the MSG Server and therefore such calls can be 
locally switched. 
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13.2 Call Deflection Service 

13.2.1 General 

The procedures specified for the Call Deflection (CD) supplementary services in 3GPP TS 23.205 [2] sub-clause 13.2 
for BICC based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.2 for SIP-I based CS Core Network shall 
be followed. The following sub-clauses describe the additional requirements related to the LCLS functionality. 

The incoming call shall be offered to the served subscriber as a basic mobile terminated call as described in the first part 
of sub-clause 6.3.2. If the Call Deflection (CD) supplementary service is active and a Call Deflection request from the 
served subscriber is accepted the call shall be forwarded towards the forwarded-to subscriber. 

The basic call establishment procedures defined in Clause 6 shall be followed for the call towards the forwarded-to 
(deflected-to) subscriber. The MSC server shall release the call leg towards the served subscriber as described in the 
sub-clause 7.1 for call clearing. 

1 3.2.2 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

13.2.3 Initial Addressing 

After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in Clause 6 for the basic mobile terminating call. If the forwarding MSC server 
supports the LCLS feature and has received the GCR IE and LCLS -Negotiation IE from a preceding node in the I AM it 
shall then forward the GCR IE and the resulting LCLS -Negotiation IE to the succeeding node. 

1 3.2.4 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

13.2.5 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 

13.2.6 Example 
13.2.6.1 Connection Model 

Figure 13.2.6.1.1 shows the network model for Call Deflection (CD). 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After a call deflection request is accepted the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 
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The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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Connection Model 3: CD, After Answer, Call locally switched 
Figure 13.2.6.1.1: Connection Model for Call Deflection 
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13.2.6.2 Basic Sequence 

Figures 13.2.6.2.1 and 13.2.6.2.2 show the message sequence example for the call deflection with a possible notification 
to the calling party using an announcement. In the example the sMSC server optionally requests the sMGW to play an 
announcement and to notify the announcement completion. The sMSC server requests the establishment of the call and 
the bearer towards the forward-to subscriber after the possible announcement has completed. In this example the calling 
subscriber (oUE) and the forwarded-to subscriber (tUE) belong to the same BSS (marked as oBSS and tBSS) and the 
CN permits LCLS. This example is based on examples from clause 6. 
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For call establishment towards served subscriber sUE see basic call establishment, subclause 6.3.2, Steps 1 - 24 
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Figure 13.2.6.2.1: CD, Call Establishment Flow 

The incoming call is offered to the served subscriber as a basic mobile terminated call as described in the first 
part of sub-clause 6.3.2. The Call Deflection (CD) supplementary service is active and a Call Deflection is 
requested from the served subscriber sUE. 

The Call Deflection is accepted. 

The sMSC server initiates call clearing towards the sUE by sending a DISCONNECT message. 

Upon receiving the DISCONNECT message the sUE sends a RELEASE message to the core network. 

The sMSC server sends the RELEASE COMPLETE message to the sUE. 

The sMSC server request the sBSS to release the associated dedicated resource(s) by sending CLEAR 
COMMAND message. 

The sBSS informs the sMSC server that the associated dedicated resource(s) has been successfully cleared 
with the CLEAR COMPLETE message. 

The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 
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9. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

10. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

11. The GMSC server forwards the CPG message with the Generic Notification Indicator parameter set to "Call 
is diverting" to the preceding node. 

12. The oMSC server notifies the calling user (oUE) about call forwarding. 

13. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 
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23. For succeeding signalling sequence see basic call establishment, figures 6.3.2.2 and 6.3.2.3, steps 18-32 
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Figure 13.2.6.2.2: CD, Call Establishment Flow (continuation of figure 13.2.6.2.1) 

14. If the sMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the I AM message 
containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

15. The tMSC server pages the forwarded-to subscriber (tUE). 

16. The tMSC server performs call Setup. 

17. The tUE confirms the call. 
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18. The tMSC server requests the tMGW to prepare for the network side bearer establishment (T7). 

19. After the tMGW has repHed with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec and if LCLS is supported, the LCLS -Negotiation IE. 

20. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

21. The GMSC server transfers the APM message. 

22. Based on the returned LCLS -Negotiation IE the oMSC server determines whether LCLS is allowed in the 
core network and if LCLS -Configuration update is needed. 

If codec modification is required then the oMSC server performs codec negotiation according to 3GPP TS 
23.153 [4]. 

23. When performing further call establishment the procedure between the calling subscriber (oUE) and the 
forwarded-to subscriber (tUE) is the same as specified in steps 18 - 32 of sub-clause 6.3.2.1. 

24. Since the received ANM message indicated "LCLS is feasible but not yet connected" the oMSC server 
checks if LCLS -Configuration updated is needed and if so the oMSC server calculates the new LCLS- 
Configuration value based on the latest received LCLS -Negotiation IE. 

25. The oMSC server requests the oBSS to connect LCLS and if configuration updated is needed, it includes the 
LCLS-Configuration IE in the LCLS_CONNECT_CONTROL message. 

26a. Since the ESS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "the call is locally 
switched" . 

26b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

27. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

28. The iMSC server transfers the change of the LCLS status to the sMSC server. 

29. The sMSC server transfers the change of the LCLS status to the tMSC server. 

13.3 Line identification Services 

13.3.1 Calling Line Identification Presentation (CLIP) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Calling Line Identification Presentation (CLIP) service. 

13.3.2 Calling Line Identification Restriction (CLIR) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Calling Line Identification Restriction (CLIR) service. 

13.3.3 Connected Line Identification Presentation (COLP) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Connected Line Identification Presentation (COLP) service. 

13.3.4 Connected Line Identification Restriction (COLR) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Connected Line Identification Restriction (COLR) service. 
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13.4 Call Forwarding Services 

13.4.1 Principles 

The procedures specified for the Call Forwarding services in 3GPP TS 23.205 [2] sub-clause 13.4 for BICC based CS 
Core Network and in 3GPP TS 23.231 [3] sub-clause 13.4 for SIP-I based CS Core Network shall be followed. The 
following sub-clauses describe the additional requirements related to the LCLS functionality. 

13.4.2 Call Forwarding Unconditional (CFU) 

1 3.4.2.1 Notification to the Calling Subscriber 

If the GMSC server determines that a call should be forwarded without being offered to the served mobile subscriber 
and the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, the GMSC server shall send a notification to the preceding node. If the GMSC server supports the LCLS 
feature and receives the LCLS -Negotiation IE from the preceding node it may modify the preferences based on its own 
requirements, as described in sub-clause 4.2, and it shall return the resulting LCLS -Negotiation IE to the preceding 
node. 

If the notification is implemented using intermediate tones or announcements the GMSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

1 3.4.2.2 Initial Addressing 

If the incoming call is to be forwarded without being offered to the served mobile subscriber the call towards the 
forwarded-to subscriber is established as for a basic call. After the possible generation of in-band information has been 
completed the initial addressing towards the forwarded-to subscriber is performed as described in the clause 6 for the 
basic mobile terminating call. If the GMSC server supports the LCLS feature and receives the GCR IE and LCLS- 
Negotiation IE from a preceding node in the I AM it shall forward the GCR and the resulting LCLS -Negotiation IE to 
the succeeding node. 

13.4.2.3 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

1 3.4.2.4 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 

13.4.2.5 Example 
13.4.2.5.1 Connection Model 

Figure 13.4.2.5.1.1 shows the network model for call forwarding unconditional. The oMSC server seizes one context 
with two bearer terminations in the oMGW. The bearer termination Tl is used for the bearer towards the oBSS (calling 
subscriber) and the bearer termination T2 is used for the bearer towards the GMSC selected iMGW. The GMSC server 
seizes one context with two bearer terminations in the iMGW. The bearer termination T4 is used for the bearer towards 
the tMSC server selected tMGW and the bearer termination T3 is used for the bearer towards the preceding oMGW. 
The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T5 is used for 
the bearer towards the GMSC selected iMGW and bearer termination T6 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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Connection Model 2: After CFU and answer, Call is locally switched 
Figure 13.4.2.5.1.1: Connection Model for Call Forwarding Unconditional 

Basic Sequence 



Figures 13.4.2.5.2.1 and 13.4.2.5.2.2 show the message sequence example for the call forwarding unconditional with a 
possible notification to the calling party using an announcement. In the example the GMSC server optionally requests 
the MGW to play an announcement and to notify the announcement completion, after the bearer to the incoming side 
has been established. When the possible announcement has completed the GMSC server requests the establishment of 
the call and the bearer towards the forward-to subscriber. 

In this example the calling subscriber (oUE) and the forwarded-to subscriber (tUE) belong to the same BSS (marked as 
oBSS and tBSS) and the CN permits LCLS. The example is based on examples from clause 6. 
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Figure 13.4.2.5.2.1: CFU, Call Establishment Flow 

1. Service Request handling. 

2. Originating Call SETUP. 

3. If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

4. The oMSC server sends the lAM message including supported codecs list, GCR with encapsulated oBSS ID, 
and configures the LCLS-Negotiation IE. 

5. The GMSC server determines that call should be forwarded because of the Call Forwarding Unconditional 
supplementary service and that notification should be send towards the calling party (oUE). 

6. Since bearer must be established for the announcement/tone to be sent to the calling party the GMSC server 
selects the MGW and requests the seizure of the incoming network side bearer termination (T3). 

7. The GMSC server transfers the APM message with the selected codec and since LCLS is supported the 
currently negotiated LCLS-Negotiation IE. 

8a. When the bearer information is received the oMSC server requests the seizure of the network side bearer 
termination (T2). 
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8b. After the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination (Tl). 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 

9. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

10. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

IL When the access assignment is completed the oMSC server sends the Continuity (COT) message to the 
GMSC server. 

12. The GMSC server sends the ACM message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

13. The GMSC server provides the iMGW with the announcement/tone identification and requests the iMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

14. The oMSC server notifies the calling user (oUE) about call forwarding. 
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24. For succeeding signalling sequence see basic call establishment, figures 6.3.2.2 and 6.3.2.3, steps 18-32 



L i I 

I 25. If "LCLS-Configuration update needed" 
j determine new value of LCLS-Configuration IE 



(LCLS- 



26 

(LCLS-i 



LQLS_CONNECr_CONTROL 

Stcitus-Control = 

Configuration]) 



Connection-; 
conhect", [LCLS 



27a. LCLS_CONNECT_CONTROL_ACK 
BSS-Statu s = "call is locc lly switched' *) 



28. LCLS stai us update: 
BICCAPM[LCLS-Status = 




LCLS connected"] 



29. LCLS status 
BICC APM [LCLS 



Status = "cal 



update: 
Status = "LCLlS connected"] 



27b. LCLS NOTIFICATION 



is locally switched") 



(LCLS-BSS- 



Figure 13.4.2.5.2.2: CFU, Call Establishment Flow (continuation of figure 13.4.2.5.2.1) 

15. The iMGW notifies the GMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

16. If the GMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the lAM 
message containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

17. The tMSC server pages the forwarded-to subscriber (tUE). 

18. The tMSC server performs call Setup. 

19. The tUE confirms the call. 

20. The tMSC server requests the tMGW to prepare for the network side bearer establishment (T5). 

21. After the tMGW has replied with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec and if LCLS is supported, the LCLS-Negotiation IE. 

22. The GMSC server transfers the APM message with the LCLS-Negotiation IE. If codec modification is 
required then the GMSC server initiates codec negotiation according to 3GPP TS 23.153 [4], and includes the 
codec related information within the same APM message. 
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23. Based on the returned LCLS -Negotiation IE the oMSC server determines whether LCLS is allowed in the 
core network and if LCLS -Configuration update is needed. 

If codec modification is required then the oMSC server performs codec negotiation according to 3GPP TS 
23.153 [4]. 

24. When performing further call establishment the procedure between the calling subscriber (oUE) and the 
forwarded-to subscriber (tUE) is the same as specified in steps 18 - 32 of sub-clause 6.3.2.1. 

25. Since the received ANM message indicated "LCLS is feasible but not yet connected" the oMSC server 
checks if LCLS -Configuration updated is needed and if so the oMSC server calculates the new LCLS- 
Configuration value based on the latest received LCLS -Negotiation IE. 

26. The oMSC server requests the oBSS to connect LCLS and if configuration updated is needed, it includes the 
LCLS-Configuration IE in the LCLS_CONNECT_CONTROL message. 

NOTE: If codecs need to be modified for TrFO (AoIP), then the oMSC can utilize Assignment (modify) or 
Internal Handover Enquiry before sending LCLS_CONNECT_CONTROL message. 

27a. Since the ESS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "the call is locally 
switched" . 

27b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS -BSS -Status IE set to "the call is 
locally switched" . 

28. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

29. The iMSC server transfers the change of the LCLS status to the tMSC server. 

13.4.3 Call Forwarding on mobile subscriber Busy (CFB) 
13.4.3.1 Network Determined User Busy (NDUB) 

13.4.3.1.1 General 

The incoming call that meets mobile subscriber busy with the condition Network Determined User Busy (NDUB) shall 
be forwarded towards the forwarded-to subscriber without being offered to the served mobile subscriber. The basic call 
establishment procedures defined in the clause 6 shall be followed for the call towards the forwarded-to subscriber. 

13.4.3.1.2 Notification to the Calling Subscriber 

If the GMSC server determines that a call should be forwarded without being offered to the served mobile subscriber 
and the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, the GMSC server shall send a notification to the preceding node. If the GMSC server supports the LCLS 
feature and receives the LCLS -Negotiation IE from the preceding node it may modify the preferences based on its own 
requirements, as described in sub-clause 4.2, and it shall return the resulting LCLS -Negotiation IE to the preceding 
node. 

If the notification is implemented using intermediate tones or announcements the GMSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

13.4.3.1.3 Initial Addressing 

If the incoming call is to be forwarded without being offered to the served mobile subscriber the call towards the 
forwarded-to subscriber is established as for a basic call. After the possible generation of in-band information has been 
completed the initial addressing towards the forwarded-to subscriber is performed as described in the clause 6 for the 
basic mobile terminating call. If the GMSC server supports the LCLS feature and receives the GCR IE and LCLS- 
Negotiation IE from a preceding node in the I AM it shall forward the GCR and the resulting LCLS -Negotiation IE to 
the succeeding node. 
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13.4.3.1 .4 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

13.4.3.1.5 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 

13.4.3.1.6 Example 

The same example as for Call Forwarding Unconditional applies. 

13.4.3.2 User Deternnined User Busy (UDUB) 

13.4.3.2.1 General 

The incoming call shall be offered to the served subscriber as a normal call. When the call meets mobile subscriber busy 
with the condition User Determined User Busy (UDUB) it shall be forwarded towards the forwarded-to subscriber. The 
basic call establishment procedures defined in the clause 6 shall be followed for the call towards the forwarded-to 
subscriber. 

1 3.4.3.2.2 Call Clearing to the Served Subscriber 

When the MSC server determines that the call shall be forwarded due to the UDUB it shall release the call leg towards 
the served subscriber as described in the sub-clause 7.1 for call clearing. 

1 3.4.3.2.3 Notification to the Calling Subscriber 

If the MSC server determines that a call should be forwarded and the served mobile subscriber has requested that the 
calling subscriber shall receive a notification about the call forwarding, the MSC server shall send a notification to the 
preceding node. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

1 3.4.3.2.4 Initial Addressing 

If the incoming call is to be forwarded the call towards the forwarded-to subscriber is established as for a basic call. 
After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in the clause 6 for the basic mobile terminating call. If the forwarding MSC server 
supports the LCLS feature and has received the GCR IE and LCLS -Negotiation IE from a preceding node in the I AM it 
shall then forward the GCR IE and the resulting LCLS -Negotiation IE to the succeeding node. 

NOTE: If LCLS has been successfully negotiated to this point the oMSC will have received back the LCLS- 

Negotiation and LCLS Status may have indicated that the call can be locally switched but since the called 
subscriber did not answer the call is still switched through the CN at this point. 

1 3.4.3.2.5 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

1 3.4.3.1 .6 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 
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13.4.3.2.7 



Example 



13.4.3.2.7.1 



Connection Model 



Figure 13.4.3.2.7.1.1 shows the network model for call forwarding busy UDUB. 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After call forwarding busy UDUB is detected the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 

The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 



Control plane link which transmits signalling 

User plane link path through ON, connected or disconnected 



User plane link which transmits real user plane data within BSS and UEs 

User plane link which transmits real user plane data in backward direction 
from the ON towards oUE (e.g. announcement/tone, network provided 
ring-back tone) 
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SUE 



Connection Model 1: Before CFB (UDUB) 



oUE 



Control 
Signalling 




Connection Model 2: After CFB (UDUB), Announcement towards calling party 
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tUE 



oUE 



Control 
Signalling 




13.4.3.2.7.2 



Connection Model 3: CFB (UDUB), After Answer, Call locally switched 
Figure 13.4.3.2.7.1.1: Connection Model for Call Forwarding Busy UDUB 

Basic Sequence 



Figure 13.4.3.2.7.2.1 shows the message sequence example for the call forwarding UDUB with a possible notification 
to the calHng party using an announcement. In the example the sMSC server optionally requests the sMGW to play an 
announcement and to notify the announcement completion, after the bearer to the incoming side has been established. 
When the possible announcement has completed the sMSC server requests the establishment of the call and the bearer 
towards the forward-to subscriber. This example is based on examples from clause 6. 
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For call establishment towards served subscriber sUE see basic call establishment, figures 6.3.2.1 and 6.3.2.2 
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13. For succeeding signalling sequence see Call Forwarding Unconditional, figure 13.4.2.5.2.2 steps 23 -29. 



Figure 13.4.3.2.7.2.1: CFB UDUB, Call establishment flow 
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1. The sMSC server determines that call should be forwarded because of the Call Forwarding Busy UDUB 
supplementary service and that notification should be send towards the calling party (oUE). 

2. The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 

3. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

4. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

5. The GMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

6. The oMSC server notifies the calling user (oUE) about call forwarding. 

7. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

8. If the sMSC server supports LCLS it may modify the LCLS -Negotiation IE before sending the lAM message 
containing the GCR with the encapsulated oBSS ID and the LCLS -Negotiation IE. 

9. When performing further call establishment towards the forwarded-to subscriber see clause 6 and the 
procedure specified for mobile originating call. 

10. The tMSC server returns the APM message with the selected codec and if LCLS is supported, the LCLS- 
Negotiation IE. 

11. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

12. The GMSC server transfers the APM message. 

13. When performing further call establishment see signalling sequence for Call Forwarding Unconditional, 
figure 13.4.2.5.2.2, steps 23 -29. 

13.4.4 Call Forwarding on No Reply (CFNRy) 

13.4.4.1 General 

The incoming call shall be offered to the served subscriber as a normal call. When the Call Forwarding on No Reply 
(CFNRy) supplementary service is active and if the call is not answered within the period of time defined by the no 
reply condition timer it shall be forwarded towards the forwarded-to subscriber. The basic call establishment procedures 
defined in the clause 6 shall be followed for the call towards the forwarded-to subscriber. 

13.4.4.2 Call Clearing to the Served Subscriber 

When the MSC server determines that the call shall be forwarded due to the CFNRy it shall release the call leg towards 
the served subscriber as described in the sub-clause 7.1 for call clearing. 

1 3.4.4.3 Notification to the Calling Subscriber 

If the MSC server determines that a call should be forwarded and the served mobile subscriber has requested that the 
calling subscriber shall receive a notification about the call forwarding, the MSC server shall send a notification to the 
preceding node. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 
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13.4.4.4 Initial Addressing 

If the incoming call is to be forwarded the call towards the forwarded-to subscriber is established as for a basic call. 
After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in the clause 6 for the basic mobile terminating call. If the MSC server supports the 
LCLS feature and has received the GCR IE and LCLS -Negotiation IE from a preceding node in the I AM it shall then 
forward the GCR IE and the resulting LCLS -Negotiation IE to the succeeding node. 

1 3.4.4.5 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.L2.2 for the intermediate node and in sub-clause 6.L1.4 for the oMSC server 
shall be applied. 

1 3.4.4.6 LCLS Through-Connection 

The procedure specified in sub-clause 6.LL5 shall be applied. 

13.4.4.7 Example 



13.4.4.7.1 



Connection Model 



Figure 13.4.4.7. LI shows the network model for Call Forwarding on No Reply (CFNRy). 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After Call Forwarding on No Reply is detected the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 

The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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Control 
Signalling 




Connection Model 2: After CFNRy, Announcement towards calling party 



tUE 



oUE 



Control 
Signalling 




13.4.4.7.2 



Connection Model 3: CFNRy, After Answer, Call locally switched 
Figure 13.4.4.7.1.1: Connection Model for Call Forwarding on No Reply 

Basic Sequence 



Figure 13.4.4.7.2.1 shows the message sequence example for the Call Forwarding on No Reply with a possible 
notification to the calling party using an announcement. In the example the sMSC server optionally requests the sMGW 
to play an announcement and to notify the announcement completion, after the bearer to the incoming side has been 
established. When the possible announcement has completed the sMSC server requests the establishment of the call and 
the bearer towards the forward-to subscriber. This example is based on examples from clause 6. 
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For call establishment towards served subscriber sUE see basic call establishment, figures 6.3.2.1 and 6.3.2.2 
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13. For succeeding signalling sequence see Call Forwarding Unconditional, figure 13.4.2.5.2.2 steps 23 -29. 



Figure 1 3.4.4.7.2.1 : CFNRy, Call establishment flow 

1 . The sMSC server determines that call should be forwarded because of the Call Forwarding on No Reply 
supplementary service and that notification should be send towards the calling party (oUE). 

2. The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 

3. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

4. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

5. The GMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

6. The oMSC server notifies the calling user (oUE) about call forwarding. 

7. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

8. If the sMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the lAM message 
containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

9. When performing further call establishment towards the forwarded-to subscriber see clause 6, the procedure 
specified for mobile originating call. 

10. The tMSC server returns the APM message with the selected codec and if LCLS is supported, the LCLS- 
Negotiation IE. 
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11. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

12. The GMSC server transfers the APM message. 

13. When performing further call establishment see signalling sequence for Call Forwarding Unconditional, 
figure 13.4.2.5.2.2, steps 23 -29. 

13.4.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

13.4.5.1 General 

The incoming call that meets mobile subscriber unreachable shall be forwarded towards the forwarded-to subscriber 
without being offered to the served mobile subscriber. The basic call establishment procedures defined in the clause 6 
shall be followed for the call towards the forwarded-to subscriber. 

1 3.4.5.2 Rerouting by HLR 

The same handling as for Call Forwarding Unconditional applies. 

13.4.5.3 Rerouting by VLB 

The same handling as for Call Forwarding Unconditional applies. 

13.5 Call Waiting (CW) 

13.5.1 Principles 

The procedures specified for the Call Waiting supplementary service in 3GPP TS 23.205 [2] sub-clause 13.6 for BICC 
based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.6 for SIP-I based CS Core Network shall be followed 
with the following modifications: 

- The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied. 

- If the new call is accepted, the GCR of the new call is sent to the BSS in the ASSIGNMENT procedure 

The following sub-clauses describe the additional requirements related to the LCLS functionality when the Call Waiting 
supplementary service is activated for the locally switched call. 

13.5.2 Accept the new incoming call, the original call is hold 

13.5.2.1 General 

When new call arrives and is accepted, the GCR and LCLS -Configuration of the local access bearer shall be modified 
according to the new call. The MSC Server shall initiate an ASSIGNMENT REQUEST message towards the BSS 
including the GCR and LCLS -Configuration of the new call. 

13.5.2.2 Example 
13.5.2.2.1 Connection Model 

Figure 13.5.2.2. LI shows the network model for Call Waiting supplementary service of holding the original call to 
accept the new call. Termination Ti to Tg is established for original call between UE-A and UE-B. When UE-A and UE- 
B have an active call established, UE-C, which is roaming under BSS-B and MSC-B, initiates a new call towards UE-A. 
To accept the new call, UE-A holds the call with UE-B and relocates its access bearer for the new call. 

After the new call between UE-C and UE-A is established, a new context (CI -2) is seized in MGW-A. The access 
bearer termination Tg is moved from CI to CI -2 and a new network bearer towards the iMGW is created (T7). In the 
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iMGW, a new context (iC-2) is created with terminations for the bearers with MGW-A (Tg) and with MGW-B (T9). In 
MGW-B, new terminations are created for the access bearer towards UE-C (Tn) and for bearer towards iMGW (Tio). 
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Connection Model 1: Before new call incoming 




Connection Model 2: Incoming call is established, UE-B held, Announcement towards UE-B 
Figure 13.5.2.2.1.1 : Connection Model for Accept Incoming call, original call is held 



13.5.2.2.2 



Basic Sequence 



Figure 13.5.2.2.2.1 shows the message sequence example for the acceptance of new call and hold the original one. The 
ASSIGNMENT REQUEST message is sent from MSC-A to BSS-A to update the GCR stored within the BSS-A. 
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8. normal LCLS call establishment procedure between UE-A and UE-C from step 8 to 17 in 6.3.2 



9. Hold Request 



10. The session between UE-A and UE-B is put on hold 



II.HoldAck 



12. Connec: 




13. normal LCLS call establishment procedure between UE-A and UE-C from step 18 in 6.3.2 



Call is locally Swi tched 




Figure 13.5.2.2.2.1: Accept Incoming call, original call is held 

1 . UE-C sends a SETUP message to the Core Network. 

2. MSC-B responds with CALL PROCEEDING message. 

3. MSC-B sends the lAM message including supported codecs Hst, GCR with encapsulated BSS-B ID and 
LCLS-Negotiation IE. 

4. iMSC transfers the lAM message to MSC-A. 

5. MSC-A determines that UE-A is busy and that call waiting is available. 

6. MSC-A sends a SETUP message to UE-A. 

7. UE-A responds with CALL CONFIRM message. 

8. The normal LCLS call establishment procedures from step 8 to 17 in 6.3.2 are applied. 

9. UE-A requests to hold the call with UE-B. 

10. The session between UE-A and UE-B is put on hold. The procedure in 13.6.2.3.2 is applied. 

11. After the session between UE-A and UE-B is put on hold, MSC-A sends the acknowledgement to UE-A. 

12. UE-A accepts the incoming call by sending CONNECT message to MSC-A. 
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13. The normal LCLS call establishment procedures from step 18 in 6.3.2 are applied. BSS-A shall update the 
GCR and the LCLS -Configuration on receipt of the ASSIGNMENT REQUEST message for the access 
bearer. 

13.6 Call Hold (CH) 

13.6.1 Principles 

The procedures specified for the Call Hold supplementary service in 3GPP TS 23.205 [2] sub-clause 13.6 for BICC 
based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.6 for SIP-I based CS Core Network shall be followed 
with the following modifications: 

- The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied. 

- If a new call is established after the original call is held, the MSC shall generate a new GCR for the new call. 

The following sub-clauses describe the additional requirements related to the LCLS functionality when the Call Hold 
supplementary service is activated for the locally switched call. 

13.6.2 Call Hold after Answer, LCLS established 

13.6.2.1 Hold Request 

When the UE makes a request for the hold function for the locally switched call the MSC server shall request a LCLS 
break procedure described in sub-clause 7.2.1. 

The MSC server shall request the MGW to interrupt the communication on the bearer by changing the through- 
connection of the bearer termination towards the served mobile subscriber to "inactive" or by using the Isolate Bearer 
Termination Procedure. 

If an announcement is to be applied to the held party the MSC shall apply the procedure for non LCLS call defined in 
3GPP TS 23.205 [2] sub-clause 14.6 for BICC based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 14.6 for 
SIP-I based CS Core Network. 

If a handover occurs to the UE making the request for the hold function (UE-A) while the party is not intended to be re- 
connected locally then the MSC Server shall include LCLS -Connection-Status-Control set to "do not establish LCLS" 
in the HO Request message. 

13.6.2.2 Retrieval Request 

When the UE makes a request to retrieve a held call the MSC server shall stop an announcement that was applied to the 
held party. The MSC shall request the MGW to re-establish communication to the held party by changing the through- 
connection of the bearer termination towards the served mobile subscriber to be both- way through-connected or by 
using the Join Bearer Termination Procedure. 

If the call has been successfully negotiated for LCLS and an LCLS break was triggered by the CN the MSC server shall 
perform a LCLS re-establishment as described in sub-clause 7.3.1. 

NOTE: LCLS re-negotiation can occur while the call is on hold or the held call is connected to a new party (ECT) 
which may change the LCLS configuration and thus permit or prevent LCLS. 

13.6.2.3 Example 
13.6.2.3.1 Connection Model 

Figure 13.6.2.3.1.1 shows the network model for Call Hold supplementary service when LCLS was established. The 
MSC-B server seizes one context with two bearer terminations in the MGW-B. The bearer termination Tl is used for 
the bearer towards the BSS-B and the bearer termination T2 is used for the bearer towards the iMSC selected iMGW. 
The iMSC server seizes one context with two bearer terminations in the iMGW. The bearer termination T4 is used for 
the bearer towards the MSC-A server selected MGW-A and the bearer termination T3 is used for the bearer towards the 
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preceding MGW-B. The MSC-A server seizes one context with two bearer terminations in the MGW-A. The bearer 
termination T5 is used for the bearer towards the iMSC selected iMGW and bearer termination T6 is used for the bearer 
towards the BSS-A. 
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Connection Model 1: Before Call Hold, LCLS established and 
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Connection Model 2: After Hold procedure, LCLS released; Announcement towards held party 
Figure 1 3.6.2.3.1 .1 : Connection Model for Call Hold 



13.6.2.3.2 



Basic Sequence 



Figure 13.6.2.3.2.1 shows the message sequence example for the Hold procedure with a possible notification to the held 
party using an announcement. In the example the MSC server requests the MGW to play an announcement towards the 
held party. 
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For LCLS release procedure initiated by IVISC server see the corresponding signalling sequence in sub-clause 7.2.1 
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Figure 13.6.2.3.2.1 : Hold Request on LCLS call 

1 . HOLD message is received from the UE- A. 

2. The MSC-A server accepts the HOLD request. 

3. The MSC-A server requests a LCLS brealc procedure described in sub-clause 7.2. L 

4. The MSC-A server requests the MGW-A to interrupt the communication on the bearer by changing the 
through-connection of the bearer termination towards the UE-A to "inactive". 

5. The MSC-A server sends the CPG message with the Generic Notification Indicator parameter set to "remote 
hold" to the iMSC. 

6. The iMSC server transfers the CPG message to the MSC-B server. 

7. The MSC-B server sends FACILITY message with the call hold notification to the UE-B. 

8. The MSC-A server informs the UE-A that call hold is accepted with the HOLD ACKNOWLEDGE message. 

9. The MSC-A server requests the MGW-A to play an announcement towards the held party. 
Figure 13.6.2.3.2.2 shows the message sequence for the Retrieval procedure. 
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Figure 13.6.2.3.2.2: Retrieval Request and LCLS re-establishment 

1 . RETRIEVE message is received from the UE-A. 

2. The MSC-A server accepts the RETRIEVE request. 

3. The MSC-A server requests the MGW-A to stop an announcement towards the held party. 

4. The MSC-A server requests the MGW-A to re-estabHsh communication to the held party by changing the 
through-connection of the bearer termination towards the UE-A to be both- way through-connected. 

5. The MSC-A server sends the CPG message with the Generic Notification Indicator parameter set to "remote 
retrieval" to the iMSC. 

6. The iMSC server transfers the CPG message to the MSC-B server. 

7. The MSC-B server sends FACILITY message with the call hold notification to the UE-B. 

8. The MSC-A server informs the UE-A that retrieve request is accepted with the RETRIEVE 
ACKNOWLEDGE message. 

9. If the call has been successfully negotiated for LCLS the MSC-A server requests a LCLS re-establishment 
procedure as described in sub-clause 7.3. L 

13.6.3 Call Hold after Answer, LCLS not established 
13.6.3.1 Hold Request 

When the UE makes a request for the hold function for the non-local call the MSC server shall signal LCLS- 
C0NNECT_C0NTR0L message with LCLS -Connection-status-control set to "do not establish LCLS". 
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NOTE: this is to avoid the case that the party requesting hold (which is no longer intended to be connected to the 
held party) performs a handover into the same BSS and triggers local switching in the BSS. 

13.6.3.2 Retrieval Request 

When the UE makes a request to retrieve a held call the MSC server shall stop an announcement that was applied to the 
held party. The MSC shall request the MGW to re-establish communication to the held party by changing the through- 
connection of the bearer termination towards the served mobile subscriber to be both- way through-connected or by 
using the Join Bearer Termination Procedure. 

If the call has been successfully negotiated for LCLS then MSC server shall signal LCLS-CONNECT_CONTROL 
message with LCLS-Connection-status-control set to "connect". If the BSS established local switching it shall notify the 
core network. 

13.6.4 Establishment of a new call, the original call is hold 

13.6.4.1 General Principle 

The call hold procedures and call establishment procedures shall be applied with the following enhancements. 

To avoid the local switching between remote parties of the new call and the held call, the new call shall have a different 
GCR than the GCR of the original call. During the new call establishment, the MSC server serving the UE which has 
the held call and has initiated the new call shall generate a new GCR for the new call. 

The MSC server shall use the ASSIGNMENT REQUEST message to update the BSS serving the UE which has the 
held call and has initiated the new call with the new GCR and LCLS -Configuration for the new call. 

The access bearer is kept unchanged. 

13.6.4.2 Assignment Request 

During the new call establishment, the MSC server serving the UE which has the held call and has initiated the new call 
shall send the Assignment Request message to update the BSS with the new GCR and LCLS -Configuration for the new 
call. 

On receipt of Assignment Request, the BSS shall save the GCR and LCLS -Configuration in this message. 

13.6.5 Retrieval of the held call, ongoing call is on-hold/completed 
13.6.5.1 General Principle 

When the UE requests to place the new call on hold and retrieve the original call, the MSC server shall initiate normal 
call hold procedures as described in sub-clause 13.6.1 for the new call. The MSC server sends the ASSIGNMENT 
REQUEST message with the GCR and LCLS -Configuration of the original call to the BSS. The MSC server continues 
the retrieval procedure as described in sub-clause 13.6.2.2. 

When the UE requests to retrieve the original call after the active session has completed, the MSC server shall send the 
ASSIGMENT REQUEST message to the BSS to update the GCR and LCLS -Configuration for the original call. The 
MSC server continues the retrieval procedures as described in sub-clause 13.6.2.2. 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 



156 



ETSI TS 123 284 VI 0.1.0 (2011-06) 



13.6.5.2 Example call flow, Retrieval of held call after ongoing call has completed 
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Figure 13.6.5.2.1: Retrieval of held call, ongoing call has completed 

The active session between UE-A and UE-C is released. 

The RETRIEVE message is sent from UE-A to MSC-A Server. 

MSC-A server accepts the RETRIEVE request. 

MSC-A server retrieves the LCLS -Configuration and GCR for the held session and sends the 
ASSIGNMENT REQUEST message to BSS-A including the LCLS -Configuration IE and the GCR IE. 

The BSS-A returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

MSC-A server continues the sequence handling described in sub-clause 13.6.2.3.2. 



13.7 Multiparty (MPTY) 

If LCLS is established for a call it shall be released while the Multiparty (MPTY) service is utilised, see LCLS break 
procedure in clause 7.2 of this specification. After MPTY is ended LCLS may be re-established if it is still feasible, see 
LCLS re-establishment procedure in clause 7.3 of this specification. 

1 3.8 Closed User Group (CUG) 

No impact. There are no LCLS related requirements for the Closed User Group (CUG) service. 

1 3.9 Advice of Charge (AoC) 

No impact. There are no LCLS related requirements for the Advice of Charge (AoC) service. 

13.10 User-to-User Signalling (UUS) 

No impact. There are no LCLS related requirements for the User-to-User Signalling (UUS) service. 

13.11 Call Barring Services 

No impact. There are no LCLS related requirements for the Call Barring Services. 
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13.12 Explicit Call Transfer (ECT) 



In order to perform Explicit Call Transfer, if LCLS is established for the first call this will be broken when it is put on 
hold as per the procedures specified in sub-clause 13.6. If LCLS is established for the second call then the local 
switching of the call shall be released in order to be connected to the held party. 

Procedures to establish LCLS for the transferred call are not supported. 

13.13 Completion of Calls to Busy Subscriber (CCBS) 

No impact. There are no LCLS related requirements for the Completion of Calls to Busy Subscriber (CCBS) service. 

13.14 Multiple Subscriber Profile (MSP) 

No impact. There are no LCLS related requirements for the Multiple Subscriber Profile (MSP) service. 

13.15 Multicall 

There are no specific LCLS related requirements for the Multicall service. 

NOTE: If LCLS is established for any call as part of the Multicall service, then the local switching of the call will 
be released when it is put on hold as per the procedures specified in sub-clause 13.6. 

13.16 Calling Name Presentation (CNAP) 

No impact. There are no LCLS related requirements for the Calling Name Presentation (CNAP) service. 

13.17 Alternate Speech/Fax 

LCLS shall not be allowed for the Alternate Speech/Fax calls. 

13.18 Modification of the Access Bearer 

During the call establishment phase, the modification of the access bearer procedure shall be performed in accordance 
with 3GPP 23.205 [2] for a BICC based CS core network and in accordance with 3GPP TS 23.231 [3] for a SIP-I based 
CS core network. 

When the call is locally switched, if the MSC Server requires modification of the access bearer, an LCLS Break 
procedure as specified in sub-clause 7.2.1 may occur. 

13.19 GSM Fax 

LCLS shall not be allowed for the GSM Fax calls. 

13.20 Voice group call service (VGCS), Voice broadcast service 
(VBS) 

LCLS shall not be allowed when the Voice group call service (VGCS) or the Voice broadcast service (VBS) is utilised. 
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14 Interactions with Other Network Features and 
Services 

14.1 Customised Applications for Mobile network Enhanced 
Logic (CAMEL) 

No impact. There are no LCLS related requirements for Customised Applications for Mobile network Enhanced logic 
(CAMEL). 

If LCLS is established for the call and a CAMEL service requires the insertion of Tones/ Announcements, the LCLS 
procedures for Providing Tones or Announcements shall be applied as specified in sub-clause 14.6. 

If LCLS is established for the call and a CAMEL service requires the user-plane to be manipulated within the Core 
Network, the LCLS procedures for breaking LCLS shall be applied as specified in sub-clause 7.2. 

14.2 1ST 

No impact. There are no LCLS related requirements for Immediate Service Termination (1ST). 

14.3 Operator Determined Barring (ODB) 

No impact. There are no LCLS related requirements for Operator Determined Barring (ODB). 

14.4 DTMF 

No impact. There are no LCLS related requirements for DTMF. 

If LCLS is established for the call and a DTMF tone is required to be sent to the UE, the LCLS procedures for 
Providing Tones or Announcements shall be applied as specified in sub-clause 14.6. 

14.5 OR 

No impact. There are no LCLS related requirements for Optimal Routing (OR). 

14.6 Providing tones or announcements 
14.6.1 General 

Tones or announcements may be applied at any time during the call establishment or mid-call. Also periodic tones may 
be applied during the call. Prior to answer, an LCLS compatible call is still connected through the core network and so 
any tones or announcements applied at this time are handled as for normal non-LCLS calls. 

If a node wishes to apply periodic tones during the call it may either reject the LCLS entirely or may indicate that it 
requires send access in a certain direction. This is achieved during the LCLS negotiation phase as described in sub- 
clause 4.2. 

If the call is established and local switching is performed and at a later point in the call a (G)MSC Server needs to send 
a tone or announcement there are two options it may apply: 

- perform a (G)MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete 
then begin applying the tone or announcement, or 

- request temporary send access to the user plane as described in 14.6.2 
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If a node (subsequent CN node or BSS) does not support the procedures described for requesting temporary send access 
then a full LCLS break shall occur. 

14.6.2 Handling of tones or announcements during an LCLS call 

14.6.2.1 GMSC Server or internnediate node requiring temporary send access to apply 
tone or announcement 

A GMSC Server or intermediate node wishing to insert a tone or announcement may signal LCLS Negotiation IE in 
LCLS -Negotiation Request message with parameter "Need Send Backward = yes" if it needs to insert a tone or 
announcement towards the originating subscriber or "Need Send Forward = yes" if it needs to insert a tone or 
announcement towards the terminating subscriber. 

NOTE: The (G)MSC Server or intermediate node only needs to signal the LCLS -Negotiation IE in the direction 
in which it wishes to apply the tone or announcement. 

If the (G)MSC receives the LCLS -Negotiation IE in LCLS Negotiation Request Response message indicating the same 
requested send access it shall proceed to insert its tone or announcement as per a normal call handling. 

On completion of the tone or announcement the (G)MSC Server may signal LCLS -Negotiation IE in LCLS Negotiation 
Request message indicating "Need Send Backward^ no" or "Need Send Forward = no" towards preceding/succeeding 
node respectively. 

14.6.2.2 oMSC Server 

An oMSC Server wishing to insert a tone or announcement towards the terminating UE may signal LCLS Negotiation 
IE in LCLS -Negotiation Request message with parameter "Need Send Forward = yes". 

If the oMSC Server receives the LCLS -Negotiation IE in an LCLS -Negotiation Request Response message indicating 
the same requested send access then it shall proceed to insert its tone or announcement as per a normal call handling. 
Otherwise, if the received LCLS -Negotiation IE indicates requested send access is not enabled, the oMSC Server shall 
perform a MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete then begin 
applying the tone or announcement. 

On completion of the tone or announcement in the forward direction the oMSC Server may signal the LCLS- 
Negotiation IE in LCLS -Negotiation Request message to succeeding nodes indicating "Need Send Forward = no". 

If the oMSC Server wishes only to insert a tone or announcement towards its locally served UE or if the oMSC Server 
receives the LCLS -Negotiation IE indicating "Need Send Backward^ yes" it shall send LCLS-Connect-Control 
message containing the LCLS -Configuration IE set to "connected both-way in the BSS and send access DL from the 
Core Network" to the oBSS unless UL bicasting has been requested ("Need Receive Backward = yes; Need Receive 
Forward = yes") in which case it shall set the LCLS -Configuration IE to "connected both-way in the BSS and bi-casted 
UL to the CN and send access DL from the Core Network, block local DL" . 

If the oMSC Server wishes only to insert a tone or announcement towards its locally served UE and has been received 
the LCLS -Negotiation IE indicating "Need Receive Forward^ no" it may configure its Access MGW to isolate the 
access side termination from the network side termination. The oMSC Server shall send LCLS-Connect-Control 
message containing the LCLS -Configuration IE set to "connected both-way in the BSS and send access DL from the 
Core Network" to the BSS. 

If the MSC Server receives LCLS -BSS -Status indicating that the requested LCLS -Configuration was enabled then it 
shall: 

- return the LCLS -Negotiation IE indicating "Need Send Backward= yes" towards succeeding node if the send 
access was requested from succeeding node, or 

- proceed to insert its tone or announcement as per a normal call handling when the oMSC Server needs to insert a 
tone or announcement towards its locally served UE. 

If the oMSC Server receives LCLS -BSS -Status indicating that LCLS -Configuration is not supported then the oMSC 
Server shall initiate LCLS Break towards the oBSS and succeeding nodes, as described in sub-clause 7.2.1, when the 
oMSC Server needs to insert a tone or announcement towards its locally served UE. 
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On completion of the tone or announcement the oMSC Server may signal LCLS-Connect-Control message containing 
the LCLS -Configuration IE as agreed at call establishment. 

14.6.2.3 tMSC Server 

A tMSC Server wishing to insert a tone or announcement towards the originating UE may signal LCLS Negotiation IE 
in LCLS -Negotiation Request message with parameter "Need Send Backward = yes". 

If the tMSC Server receives the LCLS -Negotiation IE in LCLS -Negotiation Request Response message indicating the 
same requested send access then it shall proceed to insert its tone or announcement as per a normal call handling. 
Otherwise, if the received LCLS -Negotiation IE indicates requested send access is not enabled, the tMSC Server shall 
perform a MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete then begin 
applying the tone or announcement. 

On completion of the tone or announcement the tMSC Server may signal the LCLS -Negotiation IE to succeeding nodes 
indicating "Need Send Backward = no". 

If the tMSC Server wishes only to insert a tone or announcement towards its locally served UE or if the tMSC Server 
receives the LCLS -Negotiation IE indicating "Need Send Forward = yes" it shall send LCLS-Connect-Control message 
containing the LCLS -Configuration IE set to "connected both- way in the BSS and send access DL from the Core 
Network" to the tBSS unless UL bicasting has been requested ("Need Receive Backward = yes; Need Receive Forward 
= yes") in which case it shall set the LCLS -Configuration IE to "connected both- way in the BSS and bi-casted UL to the 
CN and send access DL from the Core Network, block local DL" . 

If the tMSC Server wishes only to insert a tone or announcement towards its locally served UE and has been received 
the LCLS -Negotiation IE indicating "Need Receive Backward^ no" it may configure its Access MGW to isolate the 
access side termination from the network side termination. The tMSC Server shall send LCLS-Connect-Control 
message containing the LCLS -Configuration IE set to "connected both-way in the BSS and send access DL from the 
Core Network" to the BSS. 

If the tMSC Server receives LCLS -BSS -Status indicating that the requested LCLS -Configuration was enabled then it 
shall: 

- return the LCLS -Negotiation IE indicating "Need Send Forward = yes" towards preceding node if the send 
access was requested from preceding node, or 

- proceed to insert its tone or announcement as per a normal call handling when the tMSC Server needs to insert a 
tone or announcement towards its locally served UE. 

If the tMSC Server receives LCLS -BSS -Status indicating that LCLS -Configuration is not supported then the tMSC 
Server shall initiate LCLS Break towards the tBSS and preceding nodes, as described in sub-clause 7.2.1, when the 
tMSC Server needs to insert a tone or announcement towards its locally served UE. 

On completion of the tone or announcement the tMSC Server may signal LCLS-Connect-Control message containing 
the LCLS -Configuration IE as agreed at call establishment. 

14.6.2.4 BSS 

If the BSS receives LCLS-Connect-Control containing LCLS -Configuration set to "connected both-way in the BSS and 
send access DL from the Core Network" and it supports this configuration it shall return LCLS -BSS -Status indicating 
that the LCLS -Configuration is supported and from then on detect any incoming data packets and insert them in the 
stream towards the locally served UE. 

If the BSS receives LCLS-Connect-Control containing LCLS -Configuration set to "connected both-way in the BSS and 
bi-casted UL to the CN and send access DL from the Core Network, block local DL" and it supports this configuration 
it shall block the local DL path from the opposite call leg and return LCLS -BSS -Status indicating that the LCLS- 
Configuration is supported. From then on it shall insert the data packets coming from the CN for that call leg in the 
stream towards the locally served UE and discard packets coming from the local path. 

If the BSS does not support the requested LCLS -Configuration it shall return LCLS -BSS -Status indicating the requested 
LCLS -Configuration is not supported; the LCLS connection is kept as it was prior to receiving the LCLS-Connect- 
Control. 
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14.6.2.5 Example of Playing Mid-Call Announcement/Tone 



14.6.2.5.1 



Connection Model 



Figure 14.6.2.5.1.1 shows the network model where the iMSC server requests the iMGW to play the 
announcement/tone directly on the bearer termination T3 (used towards the preceding oMGW) from which the signal 
shall be sent towards the oUE. The bearer termination T4 is used for the bearer towards the succeeding tMGW (i.e. 
towards the tUE). 
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14.6.2.5.2 



Announcement/ V oMGW 
tone 



Connection Model 2: Locally switched call, playing of Announcement/tone 
Figure 14.6.2.5.1.1: Connection Model, Mid-Call Announcement/tone 

Example Sequence 



Figure 14.6.2.5.2.1 shows the message sequence example for providing the oUE with an announcement/tone. In the 
example the iMSC server requests the iMGW to play an announcement/tone and to notify the announcement/tone 
completion. 
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3. lc;ls_connect_control 
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with DL sijnd access") 

4. LCLS 
(LCLS- 
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8. LCLS 

[LCLp 

CONTROL 

Corinect LCLS") 



ACK 
'call is locally 
switched") 



Cal is locally S>vitched 



Negotiation 
l-Negotiation 



Ffequest: APM 

"Need Send 

yes" 



Backward = 



. LCLS Negotikion Request 
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"lileed Send Backward = yes' 



6. MOD request (T3): 

I announcemept/Send Tone 

I MOD reply 



Negotiation 
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LPlay 

announcement/ 

tone towards oUE 



7. Notify (T3): 

Announcement completed/ 
Tone completed 



Ffequest: APM 
"Need Send 
Backward = no" 



11. LCLS Negotiation Request Response: 
APM [LCLS-l^|egotiation = "ijjeed Send 
Backward = 



Context (iC) 



Context (iC) 



tMSC tMGW tBSS 
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Figure 14.6.2.5.2.1: Mid-Call Announcement/Tone Flow 

1. The iMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

2. The iMSC server modifies the LCLS -Negotiation IE due to the announcement/tone it needs to play towards 
the oUE and sends LCLS Negotiation Request towards the preceding node the modified LCLS -Negotiation 
IE indicating "Need Send Backward = yes". 

NOTE: Other values for the initially agreed LCLS -Negotiation IE for receive or send access are 
unmodified. 

3. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS -Configuration IE set to "Connect LCLS with 
DL send access". 

4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 

5. The oMSC server confirms the oBSS is prepared for the reception of announcement/tone by sending the 
LCLS Negotiation Request Response. 

6. At reception of the LCLS status update response message indicating that requested send access is enabled the 
iMSC server provides the iMGW with the announcement/tone identification and requests the iMGW to notify 
the announcement/tone completion using the Play Announcement or Send Tone procedure. 

7. The iMGW notifies the iMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 
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10. 
11. 



The iMSC server signals to the preceding node the send access is not needed anymore by sending the LCLS 
Negotiation Request message with the LCLS -Negotiation IE indicating "Need Send Backward = no". 

The oMSC server notifies the oBSS with the LCLS-Connect-Control message that no user plane data from 
the CN will be provided. 

The oBSS replies with the LCLS-Connect-Control Ack message. 

The oMSC server confirms the oBSS has returned the LCLS connection to the status prior to the 
announcement/tone by sending the LCLS Negotiation Request Response. 



14.6.2.6 Examples with Uplink Bicasting of User Data 



14.6.2.6.1 



Connection Model 



Figure 14.6.2.6.1.1 shows the network model for the locally switched call with bicasting of user data to the Core 
Network where the oMSC server requests the oMGW to play the announcement/tone towards the originating UE. The 
dashed line in green represents call control signalling. Non-dotted lines represent the bearer carrying real user plane 
data: the solid line in turquoise represents the data from the originating UE and the solid line in yellow represents the 
data from the terminating UE. The solid line in blue represents an announcement played to the originating UE. The 
bearer termination Tl is used for the bearer towards the oBSS and the bearer termination T2 is used for the bearer 
towards the succeeding iMGW (i.e. towards the tUE). The announcement is applied directly on the bearer termination 
Tl from which the signal shall be sent towards the originating UE. 

If the oMSC server requires receiving UL data from the originating UE and the terminating UE and was sent a LCLS- 
Negotiation IE set to "Need_Receive_Backward = yes; Need_Receive_Forward = yes" to the succeeding node then 
when it needs to send the DL data to the originating UE the oMSC server will require from the oBSS to connect LCLS 
with bicasting UL and with DL send access and to block local DL. Connection model 2a is applied when the oBSS 
supports the required LCLS configuration and the announcement is played towards the originating UE. 

If the oMSC server requires receiving UL data from the originating UE and the terminating UE but was sent LCLS- 
Negotiation IE set to "Need_Receive_Backward = yes, Need_Receive_Forward = no" to the succeeding node and was 
received the LCLS -Negotiation IE set to "Need_Receive_Forward = no" then it may configure its oMGW to isolate the 
access side termination (Tl) from the network side termination (T2). When the oMSC server needs to send the DL data 
to the originating UE it requests the oBSS to connect LCLS with DL send access. Connection model 2b applies when 
the oBSS supports the required LCLS configuration and then the oBSS inserts the announcement from the Core 
Network towards the originating UE. 



tUE 



oue: 




5V 



Connection Model 1 : Locally switched call with bicasting of user data to CN 
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tUE 



oue; 




Connection Model 2a: Locally Switched Call with Bicasting of User Data to CN and with Blocked 

Local DL Data, Playing of Announcement/tone 



tUE 



oUE 




Connection Model 2b: Locally Switched Call with Bicasting of User Data to CN and Isolation of 

Access Side, Playing of Announcement/tone 

Figure 14.6.2.6.1.1: Connection Model, LCLS with UL Bicasting and Mid-Call Announcement/tone 



14.6.2.6.2 



Example Sequences with Uplink Bicasting of User Data 



Figure 14.6.2.6.2.1 shows the message sequence example for providing the originating UE with an announcement/tone. 
In the example the call is locally switched with bicasting of user data to the Core Network. The oMSC server requests 
the oBSS to connect LCLS with bicasting UL and with DL send access and to block local DL. The oMSC server 
requests the oMGW to play an announcement/tone and to notify the announcement/tone completion. 
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Figure 14.6.2.6.2.1: Mid-Call Announcement/Tone Flow with Block Local Data Request 

The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way 
in the BSS and bi-casted UL to the CN and send access DL from the Core Network, block local DL". 

The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 

At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is 
supported the oMSC server provides the oMGW with the announcement/tone identification and requests the 
oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no 
longer needed. 

The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with bicasting of 
user data to the Core Network. 



14.6.2.6.3 



Example Sequence when Access Side Termination is isolated in MGW 



Figure 14.6.2.6.3.1 shows the message sequence example for providing the originating UE with an announcement/tone. 
Since other CN nodes didn't requested receiving UL data from the originating UE the oMSC server may configure its 
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oMGW to isolate the access side termination from the network side termination. In the example the oMSC server 
requests the oMGW to play an announcement/tone and to notify the announcement/tone completion. 
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Figure 14.6.2.6.3.1: Mid-Call Announcement/Tone Flow when Access Side Termination is Isolated in 

MGW 

1. The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

2. If the LCLS negotiation indicated that any succeeding node does not require the UL data from the oUE then 
the oMSC server requests the oMGW to isolate the access side termination Tl from the network side 
termination T2. 



3. 



NOTE 1 : the MOVE command (Isolate Bearer termination procedure) is not required if Tl has been 
already moved from the context oC during the call establishment procedure. 

NOTE 2: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way 
in the BSS and send access DL from the Core Network". 



4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 
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5. At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is 
supported the oMSC server provides the oMGW with the announcement/tone identification and requests the 
oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

6. The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

7. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no 
longer needed. 

8. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with bicasting of 
user data to the Core Network 

9. The oMSC server may send to the oMGW request to move the access side termination Tl to context oC with 
the network side termination T2. 

NOTE 3: Steps 9 is optional and not needed if step 2 is not performed. 

NOTE 4: If the MSC server has used the Change Through-Connection procedure in step 2 instead of the 
Isolate Bearer termination procedure then the MSC server will use the Change Through- 
Connection procedure to request the MGW to change the through-connection of the bearer to be 
both- way through-connected. 

14.7 Global Text Telephony 

LCLS shall not be allowed for Global Text Telephony. 

14.8 Emergency Calls 

LCLS shall not be allowed for Emergency Calls. 

1 4.9 Subscriber and equipment trace 

No impact. There are no LCLS related requirements for Subscriber and Equipment Trace. 

14.10 Customized Alerting Tone 

14.10.1 Audio CAT 

No impact. There are no LCLS related requirements for Audio CAT. 

14.10.2 Multimedia CAT 

LCLS shall not be allowed for multimedia calls. 

14.1 1 Tandem Free Operation (TFO) 

No impact. There are no LCLS related requirements for Tandem Free Operation (TFO). 

LCLS may be activated for calls that use TFO, but the TFO operation is interrupted for the time that the call is locally 
switched. If LCLS is broken in the middle of a call, the TFO operation may resume, if still applicable. 

14.12 Transcoder Free Operation (TrFO) 

No impact. There are no LCLS related requirements for Transcoder Free Operation (TrFO). 
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14.13 CS Data Calls 



LCLS shall not be allowed for CS Data Calls. 



14.14 RTP Multiplexing 

No impact. There are no LCLS related requirements for RTP Multiplexing. 



15 Tunnelling 



The tunnelling procedures shall be applied in accordance with 3GPP TS 23.205 [2]. 



1 6 Messages/Procedures and their contents 

16.1 Messages between (G)MSC servers 

16.1.1 General 

The BICC messages between (G)MSC servers on Nc interface are specified in 3GPP TS 23.205 [2]. The SIP methods 
and corresponding responses that shall be supported between (G)MSC servers on Nc interface are specified in 
3GPP TS 29.231 [10]. The LCLS related information exchanged in these messages and encapsulated in the 
corresponding SIP messages is specified below and in 3GPP TS 29.205 [6]. 

The MAP messages used for inter-MSC handover between Anchor and Target MSC-Server (E-interface) are specified 
in 3GPP TS 23.205 [2] and 3GPP TS 23.009[9]. The LCLS related information exchanged in these messages is 
specified below and in 3GPP TS 29.002 [12]. 

16.1.2 Initial Address 

Table 16.1.2.1 indicates the LCLS related information which is exchanged between the MSC servers in the Initial 
Address (BICC: lAM or SIP-I: INVITE request with encapsulated ISUP lAM) message. Only the Information Elements 
required by LCLS are shown. 

Table 16.1.2.1: LCLS related information in Initial Address message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Initial Address 

(BICC: JAM or 

SIP-I: INVITE 

[lAM]) 


Forward 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network. 


LCLS-Negotiation 


C 


This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. This information 
element shall be included when LCLS is 
supported in the core network. 



16.1.3 Answer 

Table 16.1.3.1 indicates the LCLS related information which is exchanged between the MSC servers in the Answer 
(BICC: ANM or SIP-I: 200 OK final response to initial INVITE request with encapsulated ANM) message. Only the 
Information Elements required by LCLS are shown. 



ETSI 



3GPP TS 23.284 version 10.1.0 Release 10 



169 



ETSI TS 123 284 VI 0.1.0 (2011-06) 



Table 16.1.3.1: LCLS related information in Answer message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Answer 
(BICC:ANMor 
SIP-l:200OK- 
INVITE [ANM]) 


Backward 


LCLS-Status 


C 


This information element identifies the LCLS 
connection status. This information element 
shall be included when LCLS is negotiated in 
the core network. 



16.1.4 Bearer and Codec Information 

Table 16.1.4.1 indicates the LCLS related information which is exchanged between the MSC servers in the Bearer and 
Codec Information (BICC: APM) message. Only the Information Elements required by LCLS are shown. 

Table 16.1.4.1: LCLS related information in Bearer and Codec Information message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer and Codec 
Information 
(BICC: APM 


Backward 


LCLS-Negotiation 





This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. This information 
element shall be included when the APM is 
related to LCLS negotiation in Bearer and 
Codec Information messages and LCLS is 
supported in the core network. 



16.1.5 Backward LCLS Negotiation 

Table 16.1.5.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Negotiation (BICC: APM; SIP-L 183 Session Progress provisional response with encapsulated APM) message or in the 
Address Complete (BICC: ACM; SIP-I: 183 Session Progress provisional response with encapsulated ACM) message 
or in the Call Progress (BICC: CPG; SIP-I: 183 Session Progress provisional response with encapsulated CPG) 
message. Only the Information Elements required by LCLS are shown. 

Table 16.1.5.1: LCLS related information in the LCLS Negotiation message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Negotiation 

(BICC: APM; 

SIP-I: 183 Session 

Progress [APIVI]) 


Backward 


LCLS-Negotiation 


M 


This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. 



Table 16.1.5.2: LCLS related information in the Address Complete message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Address Complete 

(BICC: ACM; 

SIP-I: 183 Session 

Progress [ACM]) 


Backward 


LCLS-Negotiation 





This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. This information 
element may be included when LCLS is 
supported in the core network. 
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Table 16.1.5.3: LCLS related information in the Call Progress message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Call Progress 

(BICC: CPG; 

SIP-I: 183 Session 

Progress [CPG]) 


Backward 


LCLS-Negotiation 





This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. This information 
element may be included when LCLS is 
supported in the core network. 



16.1.6 Change of LCLS Negotiation 

Table 16.1.6.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Negotiation Request (BICC: APM or SIP-L INFO request with encapsulated APM)messages. 

Table 16.1.6.1: LCLS related information in the LCLS Negotiation Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Negotiation 

Request (BICC: 

APM or SIP-I: 

INFO [APM] 


Both 


LCLS-Negotiation 


M 


This information element indicates the 
requested LCLS configuration preference. 


LCLS Negotiation 

Request 

Acknowledge 

(BICC: APM or 

SIP-I: INFO [APM] 


Both 


LCLS-Negotiation 


M 


This information element has the same value 
as in LCLS-Negotiation request. 


Result Code 


M 


This information element indicates if the 
LCLS Negotiation request is accepted or not. 



16.1.7 LCLS Status update 

Table 16.L7.1 indicates tlie LCLS related information which is exchanged between the MSC servers in the LCLS 
Status update (BICC: APM or SIP-L INFO request with encapsulated ISUP APM) message. 

Table 16.1.7.1: LCLS related information in LCLS Status update message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Status 

update 

(BICC: APM or 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status 


M 


This information element indicates the LCLS 
connection status. This information element 
shall be included when LCLS connection 
status has changed in the BSS. 



16.1.8 Change of LCLS Status 



Table 16. L 8.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Status Change Request (BICC: APM or SIP-L INFO request with encapsulated ISUP APM) messages. 
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Table 16.1.8.1: LCLS related information in LCLS Status Change Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Status 

Change Request 

(BICC:APMor 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status-Change 


M 


This information element indicates a request 
to change the LCLS connection status in the 
BSS. 


LCLS Status 

Change Request 

Acknowledge 

(BICC:APMor 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status-Change 


M 


This information element has the same value 
as in the LCLS-Status-Change-Request 
message. 


Result Code 


M 


This information element indicates if the 
LCLS Status Change request is accepted or 
not. 
NOTE 


NOTE: A request to break LCLS shall not be rejected. 



16.1 .9 MAP_PREPARE_HANDOVER Request 

Table 16.1.9.1 indicates the LCLS related information which is exchanged between the Anchor MSC-Server and the 
Target MSC-Server (E-interface) in the MAP_PREPARE_HANDOVER Request message. 

Table 16.1.9.1: LCLS related information in MAP-Prepare-Handover Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


MAP PREPARE 

HANDOVER 

Request 


From 
Anchor 
MSC- 
Server to 
Target 
MSC- 
Server 


OCR 





This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network. 


LCLS-Negotiation 





This information element indicates the 
negotiated LCLS configuration preference 
while LCLS is established. This information 
element shall be included when LCLS is 
supported in the core network. 



1 6.2 Procedures between (G)MSC server and MGW 

The (G)MSC server and MGW procedures shall be performed in accordance with 3GPP 23.205 [2] for a BICC based 
CS core network and in accordance with 3GPP TS 23.231 [3] for a SIP-I based CS core network. 

1 6.3 Messages between MSC server and BSS 

16.3.1 General 

The procedures used on the Base Station System (BSS) to Mobile-services Switching Centre (MSC) interface for 
control of GSM services are specified in 3GPP TS 48.008 [7]. The LCLS related information exchanged in these 
procedures is specified below. 

16.3.2 Assignment Procedure between MSC-Server and BSS 

Table 16.3.2.1 indicates the LCLS related information which is exchanged between the MSC server and the BSS in the 
BSSMAP Assignment Procedure. Only the Information Elements required by LCLS are shown. 
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Table 16.3.2.1: LCLS related information in Assignment Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Assignment 
Request 


From 
MSC-S 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network 
and LCLS is successfully negotiated within 
the core network. 


LCLS-Configuration 


C 


This information element indicates the LCLS 
connection preference which shall persist in 
the BSS while LCLS is established. This 
information element shall be included when 
LCLS is supported in the core network and 
LCLS is successfully negotiated within the 
core network. 


LCLS-Connection- 
Status-Control 


c 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included when LCLS is supported in 
the core network and LCLS is successfully 
negotiated within the core network and when 
the Assignment Request message is sent 
after Answer. 


LCLS-Correlation-Not- 
Needed 





This information element shall be sent if the 
MSC-Server has detected that the call is not 
an Intra-BSS call or an Intra-network call. 
This information element informs the BSS 
that call correlation is not needed. 


Assignment 
Complete 


From BSS 


LCLS-BSS-Status 


c 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS. 



16.3.3 Handover Request Procedure between MSC-Server and BSS 

Table 16.3.3.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Request Procedure. Only the Information Elements required by LCLS are shown. 
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Table 16.3.3.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover Request 


From 
MSC-S 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network 
and LCLS is successfully negotiated within 
the core network. 


LCLS-Connection- 
Status-Control 


C 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included when LCLS is supported in 
the core network and LCLS is successfully 
negotiated within the core network. 


LCLS-Configuration 


c 


This information element indicates the LCLS 
connection preference which shall persist in 
the BSS while LCLS is established. This 
information element shall be included when 
LCLS is supported in the core network and 
LCLS is successfully negotiated within the 
core network. 


Handover Request 
Ack 


From BSS 


LCLS-BSS-Status 


c 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS. 



16.3.4 Handover Complete Procedure between MSC-Server and BSS 

Table 16.3.4.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Complete Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.4.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover 
Complete 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS. 



16.3.5 Handover Performed Procedure between MSC-Server and BSS 

Table 16.3.5.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Performed Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.5.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover 
Performed 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS. 
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16.3.6 Internal Handover Command Procedure between MSC-Server and 
BSS 

Table 16.3.6.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Internal Handover Command Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.6.1: LCLS related information in Internal Handover Command Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Internal Handover 
Command 


From 
MSC-S 


LCLS-Connection- 
Status-Control 


C 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included when LCLS is supported in 
the core network, LCLS is successfully 
negotiated within the core network, and 
LCLS-Connection-Status-Control indicating 
"Connect" has not previously been sent to the 
BSS. 



16.3.7 LCLS Connection Procedure between MSC-Server and BSS 

Table 16.3.7.1 indicates the LCLS Connection Procedure and related information, which is exchanged between the 
MSC server and the BSS. Only the Information Elements required by LCLS are shown. 

Table 16.3.7.1: LCLS Connection Procedure between MSC-Server and BSS 



Procedures 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS-Connect- 
Control 


From 
MSC-S 


LCLS-Connection- 
Status-Control 





This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. 


LCLS-Configuration 





This information element indicates the LCLS- 
Configuration. 


LCLS Connect 
Control Ack 


From BSS 


LCLS-BSS-Status 


M 


This information element notifies CN of the 
LCLS connection status in the BSS. 



16.3.8 LCLS Notification Procedure between IVISC-Server and BSS 

Table 16.3.8.1 indicates the LCLS Notification Procedure and related information, which is exchanged between the 
MSC server and the BSS. Only the Information Elements required by LCLS are shown. 
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Table 16.3.8.1: LCLS Notification Procedures between MSC-Server and BSS 



Procedures 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS-Notification 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included when 
BSS changes the LCLS connection status. 


LCLS-Break-Request 


C 


This information element indicates if the 
LCLS break request is ordered from CN. This 
information element shall be included when 
BSS determines the local switching should be 
disconnected. 


N0TE1 : LCLS-BSS-Status and LCLC-Break-Request lEs are mutually exclusive. 
N0TE2: One of those IE shall be present in the LCLS Notification message. 
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Bearer Redirect 



Bearer Redirect mechanisms within BICC based CS core network may be applied as specified in 3GPP TS 23.205 [2]. 
Bearer Redirect is not supported within SIP-I based CS core network, see 3GPP TS 23.231 [3]. 

1 8 (G)MSC MGW Tandeming 

It is FFS the impacts to (G)MSC MGW Tandeming procedure as specified in 3GPP TS 23.205 [2]. 



19 



Timers 



The Timers as defined for a BICC based CS Core Network shall be applied as defined in 3GPP TS 23.205 [2]. 
The Timers as defined for a SIP-I based CS Core Network shall be applied as defined in 3GPP TS 23.231 [3]. 



20 Multiple Realms 



The principles for multiple IP realms shall be applied as defined in 3GPP TS 23.205 [2]. 
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